{ "summary": { "snap": { "added": [], "removed": [], "diff": [] }, "deb": { "added": [ "linux-image-6.8.0-147-generic", "linux-modules-6.8.0-147-generic" ], "removed": [ "linux-image-6.8.0-146-generic", "linux-modules-6.8.0-146-generic" ], "diff": [ "apparmor", "curl", "libapparmor1", "libcurl4t64", "libpam-systemd", "libsystemd-shared", "libsystemd0", "libudev1", "linux-image-virtual", "openssh-client", "openssh-server", "openssh-sftp-server", "python3-jwt", "python3-urllib3", "snapd", "systemd", "systemd-dev", "systemd-resolved", "systemd-sysv", "systemd-timesyncd", "tzdata", "udev" ] } }, "diff": { "deb": [ { "name": "apparmor", "from_version": { "source_package_name": "apparmor", "source_package_version": "4.0.1really4.0.1-0ubuntu0.24.04.8", "version": "4.0.1really4.0.1-0ubuntu0.24.04.8" }, "to_version": { "source_package_name": "apparmor", "source_package_version": "4.0.1really4.0.1-0ubuntu0.24.04.9", "version": "4.0.1really4.0.1-0ubuntu0.24.04.9" }, "cves": [], "launchpad_bugs_fixed": [ 2083548 ], "changes": [ { "cves": [], "log": [ "", " * Fix transmission-daemon timeout inside systemd confinement. (LP: #2083548)", "" ], "package": "apparmor", "version": "4.0.1really4.0.1-0ubuntu0.24.04.9", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2083548 ], "author": "Willow Carlson-Huber ", "date": "Fri, 18 Sep 2026 12:52:55 -0500" } ], "notes": null, "is_version_downgrade": false }, { "name": "curl", "from_version": { "source_package_name": "curl", "source_package_version": "8.5.0-2ubuntu10.15", "version": "8.5.0-2ubuntu10.15" }, "to_version": { "source_package_name": "curl", "source_package_version": "8.5.0-2ubuntu10.16", "version": "8.5.0-2ubuntu10.16" }, "cves": [ { "cve": "CVE-2026-86409", "url": "https://ubuntu.com/security/CVE-2026-86409", "cve_description": "Setting `CURLOPT_AWS_SIGV4` to NULL does not disable SigV4 authentication, contrary to expectations and documentation. A subsequent transfer on the same handle still sends an `Authorization: AWS4-HMAC-SHA256` header to whatever URL is set next, leaking state information.", "cve_priority": "low", "cve_public_date": "2026-10-14 06:00:00 UTC" }, { "cve": "CVE-2026-86414", "url": "https://ubuntu.com/security/CVE-2026-86414", "cve_description": "A HTTP proxy can trick libcurl into sending the origin's credentials (Basic password, or a Negotiate/Kerberos ticket) to the proxy itself, by answering the `CONNECT` tunnel request with 401 `WWW-Authenticate:` instead of the expected 407 `Proxy-Authenticate:`.", "cve_priority": "low", "cve_public_date": "2026-10-14 06:00:00 UTC" }, { "cve": "CVE-2026-87862", "url": "https://ubuntu.com/security/CVE-2026-87862", "cve_description": "Importing a `includeSubDomains` parent HSTS entry before a longer-lived child entry, silently drops the child. Consequently, when the parent expires, the child's valid HSTS policy is lost, causing curl to issue unencrypted HTTP requests rather than upgrading to HTTPS.", "cve_priority": "low", "cve_public_date": "2026-10-14 06:00:00 UTC" }, { "cve": "CVE-2026-87863", "url": "https://ubuntu.com/security/CVE-2026-87863", "cve_description": "An authenticated HTTPS origin can supply an HSTS `max-age` value that the parser accepts, but time serialization later fails to process. On 64-bit systems, extreme max-age values compute an absolute expiry within standard time integer limits that exceeds calendar time structure bounds. During cache saves, the original HSTS file is truncated before writing a temporary replacement; when serialization fails, the temporary file is deleted, leaving an empty or partial cache. Because the save error is silently ignored during cleanup, curl exits successfully despite the data loss.", "cve_priority": "low", "cve_public_date": "2026-10-14 06:00:00 UTC" }, { "cve": "CVE-2026-87864", "url": "https://ubuntu.com/security/CVE-2026-87864", "cve_description": "Enabling `CURLOPT_CRLF` causes curl to advertise the raw input byte count in the `IMAP APPEND {N}` literal while transmitting line-ending expanded data. The server reads only N bytes for the payload, causing the remaining overflow bytes to be interpreted and executed as pipelined IMAP commands within the authenticated session.", "cve_priority": "low", "cve_public_date": "2026-10-14 06:00:00 UTC" }, { "cve": "CVE-2026-92388", "url": "https://ubuntu.com/security/CVE-2026-92388", "cve_description": "When an FTP wildcard `LIST` operation fails, libcurl omits the restoration path meant for successful listings, leaving the write callback set to the internal listing parser and the write callback data pointing directly to the easy handle. Subsequent reuse of this handle triggers an immediate crash, and cloning it via `curl_easy_duphandle()` copies this corrupted state into the duplicate. If the original handle is subsequently freed, executing a transfer on the cloned handle causes a heap use-after-free read against the dangling handle reference; alternatively, reusing the original or cloned handle while reconfiguring only `CURLOPT_WRITEDATA` (and omitting `CURLOPT_WRITEFUNCTION`) results in type confusion, forcing the internal parser to interpret incoming server response bytes into memory at the application-supplied write data pointer.", "cve_priority": "low", "cve_public_date": "2026-10-14 06:00:00 UTC" }, { "cve": "CVE-2026-92389", "url": "https://ubuntu.com/security/CVE-2026-92389", "cve_description": "libcurl's TFTP state machine fails to validate state transitions against the requested transfer direction, accepting opening server responses for both reads and writes interchangeably. A malicious TFTP server can respond to a download request in a way that forces the client into transmit mode, prompting libcurl to consume and transmit data from the handle's persistent `CURLOPT_READDATA` pointer - including data remaining from unrelated prior operations, such as an HTTP POST request executed on a reused handle.", "cve_priority": "low", "cve_public_date": "2026-10-14 06:00:00 UTC" }, { "cve": "CVE-2026-92391", "url": "https://ubuntu.com/security/CVE-2026-92391", "cve_description": "A deeply nested multipart MIME structure constructed via the public API causes a stack overflow in libcurl during normal cleanup operations. An excessive recursion depth within `curl_mime_free` leads to unbounded stack frame allocation during structure traversal, ultimately crashing the host process.", "cve_priority": "low", "cve_public_date": "2026-10-14 06:00:00 UTC" }, { "cve": "CVE-2026-94266", "url": "https://ubuntu.com/security/CVE-2026-94266", "cve_description": "libcurl could accidentally return a URL for curl_easy_getinfo's `CURLINFO_EFFECTIVE_URL` option containing credentials, even though neither the URL provided to libcurl nor the redirected URL did. The curl tool exposes the same information using the command line option `--write-out '%{url_effective}'`. This credential leak can happen when curl retrieves credentials from a `.netrc` file.", "cve_priority": "low", "cve_public_date": "2026-10-14 06:00:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-86409", "url": "https://ubuntu.com/security/CVE-2026-86409", "cve_description": "Setting `CURLOPT_AWS_SIGV4` to NULL does not disable SigV4 authentication, contrary to expectations and documentation. A subsequent transfer on the same handle still sends an `Authorization: AWS4-HMAC-SHA256` header to whatever URL is set next, leaking state information.", "cve_priority": "low", "cve_public_date": "2026-10-14 06:00:00 UTC" }, { "cve": "CVE-2026-86414", "url": "https://ubuntu.com/security/CVE-2026-86414", "cve_description": "A HTTP proxy can trick libcurl into sending the origin's credentials (Basic password, or a Negotiate/Kerberos ticket) to the proxy itself, by answering the `CONNECT` tunnel request with 401 `WWW-Authenticate:` instead of the expected 407 `Proxy-Authenticate:`.", "cve_priority": "low", "cve_public_date": "2026-10-14 06:00:00 UTC" }, { "cve": "CVE-2026-87862", "url": "https://ubuntu.com/security/CVE-2026-87862", "cve_description": "Importing a `includeSubDomains` parent HSTS entry before a longer-lived child entry, silently drops the child. Consequently, when the parent expires, the child's valid HSTS policy is lost, causing curl to issue unencrypted HTTP requests rather than upgrading to HTTPS.", "cve_priority": "low", "cve_public_date": "2026-10-14 06:00:00 UTC" }, { "cve": "CVE-2026-87863", "url": "https://ubuntu.com/security/CVE-2026-87863", "cve_description": "An authenticated HTTPS origin can supply an HSTS `max-age` value that the parser accepts, but time serialization later fails to process. On 64-bit systems, extreme max-age values compute an absolute expiry within standard time integer limits that exceeds calendar time structure bounds. During cache saves, the original HSTS file is truncated before writing a temporary replacement; when serialization fails, the temporary file is deleted, leaving an empty or partial cache. Because the save error is silently ignored during cleanup, curl exits successfully despite the data loss.", "cve_priority": "low", "cve_public_date": "2026-10-14 06:00:00 UTC" }, { "cve": "CVE-2026-87864", "url": "https://ubuntu.com/security/CVE-2026-87864", "cve_description": "Enabling `CURLOPT_CRLF` causes curl to advertise the raw input byte count in the `IMAP APPEND {N}` literal while transmitting line-ending expanded data. The server reads only N bytes for the payload, causing the remaining overflow bytes to be interpreted and executed as pipelined IMAP commands within the authenticated session.", "cve_priority": "low", "cve_public_date": "2026-10-14 06:00:00 UTC" }, { "cve": "CVE-2026-92388", "url": "https://ubuntu.com/security/CVE-2026-92388", "cve_description": "When an FTP wildcard `LIST` operation fails, libcurl omits the restoration path meant for successful listings, leaving the write callback set to the internal listing parser and the write callback data pointing directly to the easy handle. Subsequent reuse of this handle triggers an immediate crash, and cloning it via `curl_easy_duphandle()` copies this corrupted state into the duplicate. If the original handle is subsequently freed, executing a transfer on the cloned handle causes a heap use-after-free read against the dangling handle reference; alternatively, reusing the original or cloned handle while reconfiguring only `CURLOPT_WRITEDATA` (and omitting `CURLOPT_WRITEFUNCTION`) results in type confusion, forcing the internal parser to interpret incoming server response bytes into memory at the application-supplied write data pointer.", "cve_priority": "low", "cve_public_date": "2026-10-14 06:00:00 UTC" }, { "cve": "CVE-2026-92389", "url": "https://ubuntu.com/security/CVE-2026-92389", "cve_description": "libcurl's TFTP state machine fails to validate state transitions against the requested transfer direction, accepting opening server responses for both reads and writes interchangeably. A malicious TFTP server can respond to a download request in a way that forces the client into transmit mode, prompting libcurl to consume and transmit data from the handle's persistent `CURLOPT_READDATA` pointer - including data remaining from unrelated prior operations, such as an HTTP POST request executed on a reused handle.", "cve_priority": "low", "cve_public_date": "2026-10-14 06:00:00 UTC" }, { "cve": "CVE-2026-92391", "url": "https://ubuntu.com/security/CVE-2026-92391", "cve_description": "A deeply nested multipart MIME structure constructed via the public API causes a stack overflow in libcurl during normal cleanup operations. An excessive recursion depth within `curl_mime_free` leads to unbounded stack frame allocation during structure traversal, ultimately crashing the host process.", "cve_priority": "low", "cve_public_date": "2026-10-14 06:00:00 UTC" }, { "cve": "CVE-2026-94266", "url": "https://ubuntu.com/security/CVE-2026-94266", "cve_description": "libcurl could accidentally return a URL for curl_easy_getinfo's `CURLINFO_EFFECTIVE_URL` option containing credentials, even though neither the URL provided to libcurl nor the redirected URL did. The curl tool exposes the same information using the command line option `--write-out '%{url_effective}'`. This credential leak can happen when curl retrieves credentials from a `.netrc` file.", "cve_priority": "low", "cve_public_date": "2026-10-14 06:00:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: Information exposure from stale AWS SigV4 authentication.", " - debian/patches/CVE-2026-86409.patch: clear CURLAUTH_AWS_SIGV4 when", " CURLOPT_AWS_SIGV4 is set to NULL in lib/setopt.c.", " - CVE-2026-86409", " * SECURITY UPDATE: Credential exposure to an HTTP proxy in CONNECT.", " - debian/patches/CVE-2026-86414.patch: do not react to 401 responses to a", " CONNECT request in lib/cf-h1-proxy.c, lib/cf-h2-proxy.c.", " - CVE-2026-86414", " * SECURITY UPDATE: Improper handling of HSTS entries on load.", " - debian/patches/CVE-2026-87862.patch: match only the exact host, not", " parent domains, when removing duplicates while loading an HSTS file in", " lib/hsts.c.", " - CVE-2026-87862", " * SECURITY UPDATE: Data loss from out-of-range HSTS max-age.", " - debian/patches/CVE-2026-87863.patch: cap max-age to two years and skip", " entries whose expiry cannot be formatted in lib/hsts.c.", " - CVE-2026-87863", " * SECURITY UPDATE: Command injection in IMAP APPEND with CURLOPT_CRLF.", " - debian/patches/CVE-2026-87864.patch: reject APPEND when CRLF conversion", " is enabled, as it makes the upload size unknown in lib/imap.c.", " - CVE-2026-87864", " * SECURITY UPDATE: Use after free in FTP wildcard matching.", " - debian/patches/CVE-2026-92388-1.patch: stop overwriting set.write_func", " and set.out in lib/sendf.c, lib/ftp.h, lib/ftp.c, lib/ftplistparser.c,", " lib/ftplistparser.h.", " - debian/patches/CVE-2026-92388-2.patch: only use the list parser in the", " CURLWC_MATCHING state in lib/ftplistparser.c.", " - CVE-2026-92388", " * SECURITY UPDATE: Information exposure from TFTP transfer direction", " confusion.", " - debian/patches/CVE-2026-92389.patch: return CURLE_TFTP_ILLEGAL when a", " server response does not match the transfer direction in lib/tftp.c.", " - CVE-2026-92389", " * SECURITY UPDATE: Stack overflow from deeply nested MIME structures.", " - debian/patches/CVE-2026-92391.patch: free MIME handles non-recursively in", " curl_mime_free in lib/mime.c.", " - CVE-2026-92391", " * SECURITY UPDATE: Credential exposure in CURLINFO_EFFECTIVE_URL.", " - debian/patches/CVE-2026-94266.patch: return a copy of the URL without", " credentials for CURLINFO_EFFECTIVE_URL in lib/getinfo.c, lib/transfer.c,", " lib/url.c, lib/urldata.h.", " - CVE-2026-94266", "" ], "package": "curl", "version": "8.5.0-2ubuntu10.16", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Charles Cochran ", "date": "Mon, 12 Oct 2026 18:12:33 -0400" } ], "notes": null, "is_version_downgrade": false }, { "name": "libapparmor1", "from_version": { "source_package_name": "apparmor", "source_package_version": "4.0.1really4.0.1-0ubuntu0.24.04.8", "version": "4.0.1really4.0.1-0ubuntu0.24.04.8" }, "to_version": { "source_package_name": "apparmor", "source_package_version": "4.0.1really4.0.1-0ubuntu0.24.04.9", "version": "4.0.1really4.0.1-0ubuntu0.24.04.9" }, "cves": [], "launchpad_bugs_fixed": [ 2083548 ], "changes": [ { "cves": [], "log": [ "", " * Fix transmission-daemon timeout inside systemd confinement. (LP: #2083548)", "" ], "package": "apparmor", "version": "4.0.1really4.0.1-0ubuntu0.24.04.9", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2083548 ], "author": "Willow Carlson-Huber ", "date": "Fri, 18 Sep 2026 12:52:55 -0500" } ], "notes": null, "is_version_downgrade": false }, { "name": "libcurl4t64", "from_version": { "source_package_name": "curl", "source_package_version": "8.5.0-2ubuntu10.15", "version": "8.5.0-2ubuntu10.15" }, "to_version": { "source_package_name": "curl", "source_package_version": "8.5.0-2ubuntu10.16", "version": "8.5.0-2ubuntu10.16" }, "cves": [ { "cve": "CVE-2026-86409", "url": "https://ubuntu.com/security/CVE-2026-86409", "cve_description": "Setting `CURLOPT_AWS_SIGV4` to NULL does not disable SigV4 authentication, contrary to expectations and documentation. A subsequent transfer on the same handle still sends an `Authorization: AWS4-HMAC-SHA256` header to whatever URL is set next, leaking state information.", "cve_priority": "low", "cve_public_date": "2026-10-14 06:00:00 UTC" }, { "cve": "CVE-2026-86414", "url": "https://ubuntu.com/security/CVE-2026-86414", "cve_description": "A HTTP proxy can trick libcurl into sending the origin's credentials (Basic password, or a Negotiate/Kerberos ticket) to the proxy itself, by answering the `CONNECT` tunnel request with 401 `WWW-Authenticate:` instead of the expected 407 `Proxy-Authenticate:`.", "cve_priority": "low", "cve_public_date": "2026-10-14 06:00:00 UTC" }, { "cve": "CVE-2026-87862", "url": "https://ubuntu.com/security/CVE-2026-87862", "cve_description": "Importing a `includeSubDomains` parent HSTS entry before a longer-lived child entry, silently drops the child. Consequently, when the parent expires, the child's valid HSTS policy is lost, causing curl to issue unencrypted HTTP requests rather than upgrading to HTTPS.", "cve_priority": "low", "cve_public_date": "2026-10-14 06:00:00 UTC" }, { "cve": "CVE-2026-87863", "url": "https://ubuntu.com/security/CVE-2026-87863", "cve_description": "An authenticated HTTPS origin can supply an HSTS `max-age` value that the parser accepts, but time serialization later fails to process. On 64-bit systems, extreme max-age values compute an absolute expiry within standard time integer limits that exceeds calendar time structure bounds. During cache saves, the original HSTS file is truncated before writing a temporary replacement; when serialization fails, the temporary file is deleted, leaving an empty or partial cache. Because the save error is silently ignored during cleanup, curl exits successfully despite the data loss.", "cve_priority": "low", "cve_public_date": "2026-10-14 06:00:00 UTC" }, { "cve": "CVE-2026-87864", "url": "https://ubuntu.com/security/CVE-2026-87864", "cve_description": "Enabling `CURLOPT_CRLF` causes curl to advertise the raw input byte count in the `IMAP APPEND {N}` literal while transmitting line-ending expanded data. The server reads only N bytes for the payload, causing the remaining overflow bytes to be interpreted and executed as pipelined IMAP commands within the authenticated session.", "cve_priority": "low", "cve_public_date": "2026-10-14 06:00:00 UTC" }, { "cve": "CVE-2026-92388", "url": "https://ubuntu.com/security/CVE-2026-92388", "cve_description": "When an FTP wildcard `LIST` operation fails, libcurl omits the restoration path meant for successful listings, leaving the write callback set to the internal listing parser and the write callback data pointing directly to the easy handle. Subsequent reuse of this handle triggers an immediate crash, and cloning it via `curl_easy_duphandle()` copies this corrupted state into the duplicate. If the original handle is subsequently freed, executing a transfer on the cloned handle causes a heap use-after-free read against the dangling handle reference; alternatively, reusing the original or cloned handle while reconfiguring only `CURLOPT_WRITEDATA` (and omitting `CURLOPT_WRITEFUNCTION`) results in type confusion, forcing the internal parser to interpret incoming server response bytes into memory at the application-supplied write data pointer.", "cve_priority": "low", "cve_public_date": "2026-10-14 06:00:00 UTC" }, { "cve": "CVE-2026-92389", "url": "https://ubuntu.com/security/CVE-2026-92389", "cve_description": "libcurl's TFTP state machine fails to validate state transitions against the requested transfer direction, accepting opening server responses for both reads and writes interchangeably. A malicious TFTP server can respond to a download request in a way that forces the client into transmit mode, prompting libcurl to consume and transmit data from the handle's persistent `CURLOPT_READDATA` pointer - including data remaining from unrelated prior operations, such as an HTTP POST request executed on a reused handle.", "cve_priority": "low", "cve_public_date": "2026-10-14 06:00:00 UTC" }, { "cve": "CVE-2026-92391", "url": "https://ubuntu.com/security/CVE-2026-92391", "cve_description": "A deeply nested multipart MIME structure constructed via the public API causes a stack overflow in libcurl during normal cleanup operations. An excessive recursion depth within `curl_mime_free` leads to unbounded stack frame allocation during structure traversal, ultimately crashing the host process.", "cve_priority": "low", "cve_public_date": "2026-10-14 06:00:00 UTC" }, { "cve": "CVE-2026-94266", "url": "https://ubuntu.com/security/CVE-2026-94266", "cve_description": "libcurl could accidentally return a URL for curl_easy_getinfo's `CURLINFO_EFFECTIVE_URL` option containing credentials, even though neither the URL provided to libcurl nor the redirected URL did. The curl tool exposes the same information using the command line option `--write-out '%{url_effective}'`. This credential leak can happen when curl retrieves credentials from a `.netrc` file.", "cve_priority": "low", "cve_public_date": "2026-10-14 06:00:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-86409", "url": "https://ubuntu.com/security/CVE-2026-86409", "cve_description": "Setting `CURLOPT_AWS_SIGV4` to NULL does not disable SigV4 authentication, contrary to expectations and documentation. A subsequent transfer on the same handle still sends an `Authorization: AWS4-HMAC-SHA256` header to whatever URL is set next, leaking state information.", "cve_priority": "low", "cve_public_date": "2026-10-14 06:00:00 UTC" }, { "cve": "CVE-2026-86414", "url": "https://ubuntu.com/security/CVE-2026-86414", "cve_description": "A HTTP proxy can trick libcurl into sending the origin's credentials (Basic password, or a Negotiate/Kerberos ticket) to the proxy itself, by answering the `CONNECT` tunnel request with 401 `WWW-Authenticate:` instead of the expected 407 `Proxy-Authenticate:`.", "cve_priority": "low", "cve_public_date": "2026-10-14 06:00:00 UTC" }, { "cve": "CVE-2026-87862", "url": "https://ubuntu.com/security/CVE-2026-87862", "cve_description": "Importing a `includeSubDomains` parent HSTS entry before a longer-lived child entry, silently drops the child. Consequently, when the parent expires, the child's valid HSTS policy is lost, causing curl to issue unencrypted HTTP requests rather than upgrading to HTTPS.", "cve_priority": "low", "cve_public_date": "2026-10-14 06:00:00 UTC" }, { "cve": "CVE-2026-87863", "url": "https://ubuntu.com/security/CVE-2026-87863", "cve_description": "An authenticated HTTPS origin can supply an HSTS `max-age` value that the parser accepts, but time serialization later fails to process. On 64-bit systems, extreme max-age values compute an absolute expiry within standard time integer limits that exceeds calendar time structure bounds. During cache saves, the original HSTS file is truncated before writing a temporary replacement; when serialization fails, the temporary file is deleted, leaving an empty or partial cache. Because the save error is silently ignored during cleanup, curl exits successfully despite the data loss.", "cve_priority": "low", "cve_public_date": "2026-10-14 06:00:00 UTC" }, { "cve": "CVE-2026-87864", "url": "https://ubuntu.com/security/CVE-2026-87864", "cve_description": "Enabling `CURLOPT_CRLF` causes curl to advertise the raw input byte count in the `IMAP APPEND {N}` literal while transmitting line-ending expanded data. The server reads only N bytes for the payload, causing the remaining overflow bytes to be interpreted and executed as pipelined IMAP commands within the authenticated session.", "cve_priority": "low", "cve_public_date": "2026-10-14 06:00:00 UTC" }, { "cve": "CVE-2026-92388", "url": "https://ubuntu.com/security/CVE-2026-92388", "cve_description": "When an FTP wildcard `LIST` operation fails, libcurl omits the restoration path meant for successful listings, leaving the write callback set to the internal listing parser and the write callback data pointing directly to the easy handle. Subsequent reuse of this handle triggers an immediate crash, and cloning it via `curl_easy_duphandle()` copies this corrupted state into the duplicate. If the original handle is subsequently freed, executing a transfer on the cloned handle causes a heap use-after-free read against the dangling handle reference; alternatively, reusing the original or cloned handle while reconfiguring only `CURLOPT_WRITEDATA` (and omitting `CURLOPT_WRITEFUNCTION`) results in type confusion, forcing the internal parser to interpret incoming server response bytes into memory at the application-supplied write data pointer.", "cve_priority": "low", "cve_public_date": "2026-10-14 06:00:00 UTC" }, { "cve": "CVE-2026-92389", "url": "https://ubuntu.com/security/CVE-2026-92389", "cve_description": "libcurl's TFTP state machine fails to validate state transitions against the requested transfer direction, accepting opening server responses for both reads and writes interchangeably. A malicious TFTP server can respond to a download request in a way that forces the client into transmit mode, prompting libcurl to consume and transmit data from the handle's persistent `CURLOPT_READDATA` pointer - including data remaining from unrelated prior operations, such as an HTTP POST request executed on a reused handle.", "cve_priority": "low", "cve_public_date": "2026-10-14 06:00:00 UTC" }, { "cve": "CVE-2026-92391", "url": "https://ubuntu.com/security/CVE-2026-92391", "cve_description": "A deeply nested multipart MIME structure constructed via the public API causes a stack overflow in libcurl during normal cleanup operations. An excessive recursion depth within `curl_mime_free` leads to unbounded stack frame allocation during structure traversal, ultimately crashing the host process.", "cve_priority": "low", "cve_public_date": "2026-10-14 06:00:00 UTC" }, { "cve": "CVE-2026-94266", "url": "https://ubuntu.com/security/CVE-2026-94266", "cve_description": "libcurl could accidentally return a URL for curl_easy_getinfo's `CURLINFO_EFFECTIVE_URL` option containing credentials, even though neither the URL provided to libcurl nor the redirected URL did. The curl tool exposes the same information using the command line option `--write-out '%{url_effective}'`. This credential leak can happen when curl retrieves credentials from a `.netrc` file.", "cve_priority": "low", "cve_public_date": "2026-10-14 06:00:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: Information exposure from stale AWS SigV4 authentication.", " - debian/patches/CVE-2026-86409.patch: clear CURLAUTH_AWS_SIGV4 when", " CURLOPT_AWS_SIGV4 is set to NULL in lib/setopt.c.", " - CVE-2026-86409", " * SECURITY UPDATE: Credential exposure to an HTTP proxy in CONNECT.", " - debian/patches/CVE-2026-86414.patch: do not react to 401 responses to a", " CONNECT request in lib/cf-h1-proxy.c, lib/cf-h2-proxy.c.", " - CVE-2026-86414", " * SECURITY UPDATE: Improper handling of HSTS entries on load.", " - debian/patches/CVE-2026-87862.patch: match only the exact host, not", " parent domains, when removing duplicates while loading an HSTS file in", " lib/hsts.c.", " - CVE-2026-87862", " * SECURITY UPDATE: Data loss from out-of-range HSTS max-age.", " - debian/patches/CVE-2026-87863.patch: cap max-age to two years and skip", " entries whose expiry cannot be formatted in lib/hsts.c.", " - CVE-2026-87863", " * SECURITY UPDATE: Command injection in IMAP APPEND with CURLOPT_CRLF.", " - debian/patches/CVE-2026-87864.patch: reject APPEND when CRLF conversion", " is enabled, as it makes the upload size unknown in lib/imap.c.", " - CVE-2026-87864", " * SECURITY UPDATE: Use after free in FTP wildcard matching.", " - debian/patches/CVE-2026-92388-1.patch: stop overwriting set.write_func", " and set.out in lib/sendf.c, lib/ftp.h, lib/ftp.c, lib/ftplistparser.c,", " lib/ftplistparser.h.", " - debian/patches/CVE-2026-92388-2.patch: only use the list parser in the", " CURLWC_MATCHING state in lib/ftplistparser.c.", " - CVE-2026-92388", " * SECURITY UPDATE: Information exposure from TFTP transfer direction", " confusion.", " - debian/patches/CVE-2026-92389.patch: return CURLE_TFTP_ILLEGAL when a", " server response does not match the transfer direction in lib/tftp.c.", " - CVE-2026-92389", " * SECURITY UPDATE: Stack overflow from deeply nested MIME structures.", " - debian/patches/CVE-2026-92391.patch: free MIME handles non-recursively in", " curl_mime_free in lib/mime.c.", " - CVE-2026-92391", " * SECURITY UPDATE: Credential exposure in CURLINFO_EFFECTIVE_URL.", " - debian/patches/CVE-2026-94266.patch: return a copy of the URL without", " credentials for CURLINFO_EFFECTIVE_URL in lib/getinfo.c, lib/transfer.c,", " lib/url.c, lib/urldata.h.", " - CVE-2026-94266", "" ], "package": "curl", "version": "8.5.0-2ubuntu10.16", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Charles Cochran ", "date": "Mon, 12 Oct 2026 18:12:33 -0400" } ], "notes": null, "is_version_downgrade": false }, { "name": "libpam-systemd", "from_version": { "source_package_name": "systemd", "source_package_version": "255.4-1ubuntu8.17", "version": "255.4-1ubuntu8.17" }, "to_version": { "source_package_name": "systemd", "source_package_version": "255.4-1ubuntu8.18", "version": "255.4-1ubuntu8.18" }, "cves": [], "launchpad_bugs_fixed": [ 2170538 ], "changes": [ { "cves": [], "log": [ "", " * d/p/lp2170538-resolved-pick-up-new-DNSSEC-KSK-from-2024.patch: add", " the root zone KSK-2024 (key tag 38696) to the built-in DNSSEC trust", " anchor. Since 2026-10-11 the root DNSKEY RRset is signed only by", " this key, so with DNSSEC enabled and no local trust anchor file", " every lookup failed with \"missing-key\" (LP: #2170538)", "" ], "package": "systemd", "version": "255.4-1ubuntu8.18", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [ 2170538 ], "author": "CyberNative AI LLC ", "date": "Mon, 12 Oct 2026 07:36:16 +0000" } ], "notes": null, "is_version_downgrade": false }, { "name": "libsystemd-shared", "from_version": { "source_package_name": "systemd", "source_package_version": "255.4-1ubuntu8.17", "version": "255.4-1ubuntu8.17" }, "to_version": { "source_package_name": "systemd", "source_package_version": "255.4-1ubuntu8.18", "version": "255.4-1ubuntu8.18" }, "cves": [], "launchpad_bugs_fixed": [ 2170538 ], "changes": [ { "cves": [], "log": [ "", " * d/p/lp2170538-resolved-pick-up-new-DNSSEC-KSK-from-2024.patch: add", " the root zone KSK-2024 (key tag 38696) to the built-in DNSSEC trust", " anchor. Since 2026-10-11 the root DNSKEY RRset is signed only by", " this key, so with DNSSEC enabled and no local trust anchor file", " every lookup failed with \"missing-key\" (LP: #2170538)", "" ], "package": "systemd", "version": "255.4-1ubuntu8.18", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [ 2170538 ], "author": "CyberNative AI LLC ", "date": "Mon, 12 Oct 2026 07:36:16 +0000" } ], "notes": null, "is_version_downgrade": false }, { "name": "libsystemd0", "from_version": { "source_package_name": "systemd", "source_package_version": "255.4-1ubuntu8.17", "version": "255.4-1ubuntu8.17" }, "to_version": { "source_package_name": "systemd", "source_package_version": "255.4-1ubuntu8.18", "version": "255.4-1ubuntu8.18" }, "cves": [], "launchpad_bugs_fixed": [ 2170538 ], "changes": [ { "cves": [], "log": [ "", " * d/p/lp2170538-resolved-pick-up-new-DNSSEC-KSK-from-2024.patch: add", " the root zone KSK-2024 (key tag 38696) to the built-in DNSSEC trust", " anchor. Since 2026-10-11 the root DNSKEY RRset is signed only by", " this key, so with DNSSEC enabled and no local trust anchor file", " every lookup failed with \"missing-key\" (LP: #2170538)", "" ], "package": "systemd", "version": "255.4-1ubuntu8.18", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [ 2170538 ], "author": "CyberNative AI LLC ", "date": "Mon, 12 Oct 2026 07:36:16 +0000" } ], "notes": null, "is_version_downgrade": false }, { "name": "libudev1", "from_version": { "source_package_name": "systemd", "source_package_version": "255.4-1ubuntu8.17", "version": "255.4-1ubuntu8.17" }, "to_version": { "source_package_name": "systemd", "source_package_version": "255.4-1ubuntu8.18", "version": "255.4-1ubuntu8.18" }, "cves": [], "launchpad_bugs_fixed": [ 2170538 ], "changes": [ { "cves": [], "log": [ "", " * d/p/lp2170538-resolved-pick-up-new-DNSSEC-KSK-from-2024.patch: add", " the root zone KSK-2024 (key tag 38696) to the built-in DNSSEC trust", " anchor. Since 2026-10-11 the root DNSKEY RRset is signed only by", " this key, so with DNSSEC enabled and no local trust anchor file", " every lookup failed with \"missing-key\" (LP: #2170538)", "" ], "package": "systemd", "version": "255.4-1ubuntu8.18", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [ 2170538 ], "author": "CyberNative AI LLC ", "date": "Mon, 12 Oct 2026 07:36:16 +0000" } ], "notes": null, "is_version_downgrade": false }, { "name": "linux-image-virtual", "from_version": { "source_package_name": "linux-meta", "source_package_version": "6.8.0-146.146", "version": "6.8.0-146.146" }, "to_version": { "source_package_name": "linux-meta", "source_package_version": "6.8.0-147.147", "version": "6.8.0-147.147" }, "cves": [], "launchpad_bugs_fixed": [], "changes": [ { "cves": [], "log": [ "", " * Main version: 6.8.0-147.147", "" ], "package": "linux-meta", "version": "6.8.0-147.147", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [], "author": "Stefan Bader ", "date": "Thu, 24 Sep 2026 12:33:08 +0200" } ], "notes": null, "is_version_downgrade": false }, { "name": "openssh-client", "from_version": { "source_package_name": "openssh", "source_package_version": "1:9.6p1-3ubuntu13.19", "version": "1:9.6p1-3ubuntu13.19" }, "to_version": { "source_package_name": "openssh", "source_package_version": "1:9.6p1-3ubuntu13.20", "version": "1:9.6p1-3ubuntu13.20" }, "cves": [ { "cve": "CVE-2026-106552", "url": "https://ubuntu.com/security/CVE-2026-106552", "cve_description": "In sftp in OpenSSH before 10.6, a server can trigger directory traversal (causing files to be written to unintended locations) during a recursive copy operation.", "cve_priority": "medium", "cve_public_date": "2026-10-06 21:17:00 UTC" }, { "cve": "CVE-2026-106553", "url": "https://ubuntu.com/security/CVE-2026-106553", "cve_description": "In sshd in OpenSSH before 10.6, credentials can incorrectly persist after failure of a GSSAPIAuthentication authentication attempt.", "cve_priority": "medium", "cve_public_date": "2026-10-06 21:17:00 UTC" }, { "cve": "CVE-2026-106555", "url": "https://ubuntu.com/security/CVE-2026-106555", "cve_description": "In sshd in OpenSSH before 10.6, GSSAPIAuthentication authentication state can incorrectly be persisted across authentication attempts.", "cve_priority": "medium", "cve_public_date": "2026-10-06 21:17:00 UTC" }, { "cve": "CVE-2026-106582", "url": "https://ubuntu.com/security/CVE-2026-106582", "cve_description": "In sshd and ssh in OpenSSH before 10.6, an LZ77 dictionary coder can be used even though this is contraindicated by the arXiv 2609.07709 \"Crossing the Streams\" findings.", "cve_priority": "medium", "cve_public_date": "2026-10-06 21:17:00 UTC" }, { "cve": "CVE-2026-106583", "url": "https://ubuntu.com/security/CVE-2026-106583", "cve_description": "In ssh in OpenSSH before 10.6, a $ or \\ character can occur in a command-line username, leading to injection.", "cve_priority": "medium", "cve_public_date": "2026-10-07 00:17:00 UTC" }, { "cve": "CVE-2026-106584", "url": "https://ubuntu.com/security/CVE-2026-106584", "cve_description": "In ssh-keygen in OpenSSH before 10.6, certificates could have incorrect expiration times because of Daylight Saving mishandling. There can be a slightly more severe effect on users in certain Antarctic locations.", "cve_priority": "medium", "cve_public_date": "2026-10-06 21:17:00 UTC" }, { "cve": "CVE-2026-106585", "url": "https://ubuntu.com/security/CVE-2026-106585", "cve_description": "In sshd and ssh in OpenSSH before 10.6, there is no check for whether the maximum packet length is exceeded during decompression of highly compressed data.", "cve_priority": "medium", "cve_public_date": "2026-10-06 21:17:00 UTC" }, { "cve": "CVE-2026-106586", "url": "https://ubuntu.com/security/CVE-2026-106586", "cve_description": "In sshd in OpenSSH before 10.6, the restrict keyword (in authorized_keys) was supposed to be applicable to tunnel forwarding but was not, a different vulnerability than CVE-2026-73283.", "cve_priority": "medium", "cve_public_date": "2026-10-06 21:17:00 UTC" }, { "cve": "CVE-2026-106587", "url": "https://ubuntu.com/security/CVE-2026-106587", "cve_description": "In sshd in OpenSSH before 10.6, the value \"none\" for a configuration option is sometimes interpreted as a filename but was intended to mean that a feature is disabled.", "cve_priority": "medium", "cve_public_date": "2026-10-06 22:17:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-106552", "url": "https://ubuntu.com/security/CVE-2026-106552", "cve_description": "In sftp in OpenSSH before 10.6, a server can trigger directory traversal (causing files to be written to unintended locations) during a recursive copy operation.", "cve_priority": "medium", "cve_public_date": "2026-10-06 21:17:00 UTC" }, { "cve": "CVE-2026-106553", "url": "https://ubuntu.com/security/CVE-2026-106553", "cve_description": "In sshd in OpenSSH before 10.6, credentials can incorrectly persist after failure of a GSSAPIAuthentication authentication attempt.", "cve_priority": "medium", "cve_public_date": "2026-10-06 21:17:00 UTC" }, { "cve": "CVE-2026-106555", "url": "https://ubuntu.com/security/CVE-2026-106555", "cve_description": "In sshd in OpenSSH before 10.6, GSSAPIAuthentication authentication state can incorrectly be persisted across authentication attempts.", "cve_priority": "medium", "cve_public_date": "2026-10-06 21:17:00 UTC" }, { "cve": "CVE-2026-106582", "url": "https://ubuntu.com/security/CVE-2026-106582", "cve_description": "In sshd and ssh in OpenSSH before 10.6, an LZ77 dictionary coder can be used even though this is contraindicated by the arXiv 2609.07709 \"Crossing the Streams\" findings.", "cve_priority": "medium", "cve_public_date": "2026-10-06 21:17:00 UTC" }, { "cve": "CVE-2026-106583", "url": "https://ubuntu.com/security/CVE-2026-106583", "cve_description": "In ssh in OpenSSH before 10.6, a $ or \\ character can occur in a command-line username, leading to injection.", "cve_priority": "medium", "cve_public_date": "2026-10-07 00:17:00 UTC" }, { "cve": "CVE-2026-106584", "url": "https://ubuntu.com/security/CVE-2026-106584", "cve_description": "In ssh-keygen in OpenSSH before 10.6, certificates could have incorrect expiration times because of Daylight Saving mishandling. There can be a slightly more severe effect on users in certain Antarctic locations.", "cve_priority": "medium", "cve_public_date": "2026-10-06 21:17:00 UTC" }, { "cve": "CVE-2026-106585", "url": "https://ubuntu.com/security/CVE-2026-106585", "cve_description": "In sshd and ssh in OpenSSH before 10.6, there is no check for whether the maximum packet length is exceeded during decompression of highly compressed data.", "cve_priority": "medium", "cve_public_date": "2026-10-06 21:17:00 UTC" }, { "cve": "CVE-2026-106586", "url": "https://ubuntu.com/security/CVE-2026-106586", "cve_description": "In sshd in OpenSSH before 10.6, the restrict keyword (in authorized_keys) was supposed to be applicable to tunnel forwarding but was not, a different vulnerability than CVE-2026-73283.", "cve_priority": "medium", "cve_public_date": "2026-10-06 21:17:00 UTC" }, { "cve": "CVE-2026-106587", "url": "https://ubuntu.com/security/CVE-2026-106587", "cve_description": "In sshd in OpenSSH before 10.6, the value \"none\" for a configuration option is sometimes interpreted as a filename but was intended to mean that a feature is disabled.", "cve_priority": "medium", "cve_public_date": "2026-10-06 22:17:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: sftp directory traversal", " - debian/patches/CVE-2026-106552-pre1.patch: upstream: similar to scp, fix", " implicit destination path selection in sftp.c.", " - debian/patches/CVE-2026-106552.patch: upstream: sftp: be stricter in", " accepting paths returned by the in sftp-client.c, sftp.c.", " - CVE-2026-106552", " * SECURITY UPDATE: incorrect GSSAPIAuthentication auth persistence", " - debian/patches/CVE-2026-106553-1.patch: upstream: Reset GSSAPI client", " state before authentication in auth2.c, gss-serv.c, monitor.c, ssh-gss.h.", " - debian/patches/CVE-2026-106553-2.patch: upstream: Only store GSSAPI creds", " when authn succeeds in gss-serv.c, ssh-gss.h.", " - debian/patches/CVE-2026-106553-3.patch: upstream:", " ssh_gssapi_cleanup_global_client() needs a prototype in gss-serv.c, ssh-", " gss.h.", " - CVE-2026-106553", " - CVE-2026-106555", " * SECURITY UPDATE: incorrect use of LZ77 dictionary coder", " - debian/patches/CVE-2026-106582.patch: upstream: Disable LZ77 dictionary", " coder to avoid a potential in packet.c.", " - CVE-2026-106582", " * SECURITY UPDATE: invalid chars in command-line username", " - debian/patches/CVE-2026-106583-1.patch: upstream: Further restrict the", " characters allowed in a command-line in readconf.c.", " - debian/patches/CVE-2026-106583-2.patch: upstream: Add test for", " proxycommand percent expansions. in regress/percent.sh.", " - debian/patches/CVE-2026-106583-3.patch: avoid ksh-ism in regress test in", " regress/percent.sh.", " - CVE-2026-106583", " * SECURITY UPDATE: incorrect cert expiry in ssh-keygen", " - debian/patches/CVE-2026-106584.patch: upstream: Correct handling of DST", " when converting dates in misc.c.", " - CVE-2026-106584", " * SECURITY UPDATE: missing maximum packet length check", " - debian/patches/CVE-2026-106585.patch: upstream: Check that compressed", " payloads don't inflate beyond the in packet.c.", " - CVE-2026-106585", " * SECURITY UPDATE: incorrect restrict keyword usage in tunnel forwarding", " - debian/patches/CVE-2026-106586-1.patch: upstream: Propagate", " authorized_keys \"resrict\" keyword in auth-options.c.", " - debian/patches/CVE-2026-106586-2.patch: upstream: correctly check", " sshauthopt->restricted merging in regress/unittests/authopt/tests.c.", " - debian/patches/CVE-2026-106586-3.patch: upstream: simpler in", " regress/unittests/authopt/tests.c.", " - CVE-2026-106586", " * SECURITY UPDATE: \"none\" value confusion in options", " - debian/patches/CVE-2026-106587.patch: upstream: Correctly handle some", " options that accept \"none\" in servconf.c.", " - CVE-2026-106587", "" ], "package": "openssh", "version": "1:9.6p1-3ubuntu13.20", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Marc Deslauriers ", "date": "Thu, 08 Oct 2026 13:19:18 -0400" } ], "notes": null, "is_version_downgrade": false }, { "name": "openssh-server", "from_version": { "source_package_name": "openssh", "source_package_version": "1:9.6p1-3ubuntu13.19", "version": "1:9.6p1-3ubuntu13.19" }, "to_version": { "source_package_name": "openssh", "source_package_version": "1:9.6p1-3ubuntu13.20", "version": "1:9.6p1-3ubuntu13.20" }, "cves": [ { "cve": "CVE-2026-106552", "url": "https://ubuntu.com/security/CVE-2026-106552", "cve_description": "In sftp in OpenSSH before 10.6, a server can trigger directory traversal (causing files to be written to unintended locations) during a recursive copy operation.", "cve_priority": "medium", "cve_public_date": "2026-10-06 21:17:00 UTC" }, { "cve": "CVE-2026-106553", "url": "https://ubuntu.com/security/CVE-2026-106553", "cve_description": "In sshd in OpenSSH before 10.6, credentials can incorrectly persist after failure of a GSSAPIAuthentication authentication attempt.", "cve_priority": "medium", "cve_public_date": "2026-10-06 21:17:00 UTC" }, { "cve": "CVE-2026-106555", "url": "https://ubuntu.com/security/CVE-2026-106555", "cve_description": "In sshd in OpenSSH before 10.6, GSSAPIAuthentication authentication state can incorrectly be persisted across authentication attempts.", "cve_priority": "medium", "cve_public_date": "2026-10-06 21:17:00 UTC" }, { "cve": "CVE-2026-106582", "url": "https://ubuntu.com/security/CVE-2026-106582", "cve_description": "In sshd and ssh in OpenSSH before 10.6, an LZ77 dictionary coder can be used even though this is contraindicated by the arXiv 2609.07709 \"Crossing the Streams\" findings.", "cve_priority": "medium", "cve_public_date": "2026-10-06 21:17:00 UTC" }, { "cve": "CVE-2026-106583", "url": "https://ubuntu.com/security/CVE-2026-106583", "cve_description": "In ssh in OpenSSH before 10.6, a $ or \\ character can occur in a command-line username, leading to injection.", "cve_priority": "medium", "cve_public_date": "2026-10-07 00:17:00 UTC" }, { "cve": "CVE-2026-106584", "url": "https://ubuntu.com/security/CVE-2026-106584", "cve_description": "In ssh-keygen in OpenSSH before 10.6, certificates could have incorrect expiration times because of Daylight Saving mishandling. There can be a slightly more severe effect on users in certain Antarctic locations.", "cve_priority": "medium", "cve_public_date": "2026-10-06 21:17:00 UTC" }, { "cve": "CVE-2026-106585", "url": "https://ubuntu.com/security/CVE-2026-106585", "cve_description": "In sshd and ssh in OpenSSH before 10.6, there is no check for whether the maximum packet length is exceeded during decompression of highly compressed data.", "cve_priority": "medium", "cve_public_date": "2026-10-06 21:17:00 UTC" }, { "cve": "CVE-2026-106586", "url": "https://ubuntu.com/security/CVE-2026-106586", "cve_description": "In sshd in OpenSSH before 10.6, the restrict keyword (in authorized_keys) was supposed to be applicable to tunnel forwarding but was not, a different vulnerability than CVE-2026-73283.", "cve_priority": "medium", "cve_public_date": "2026-10-06 21:17:00 UTC" }, { "cve": "CVE-2026-106587", "url": "https://ubuntu.com/security/CVE-2026-106587", "cve_description": "In sshd in OpenSSH before 10.6, the value \"none\" for a configuration option is sometimes interpreted as a filename but was intended to mean that a feature is disabled.", "cve_priority": "medium", "cve_public_date": "2026-10-06 22:17:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-106552", "url": "https://ubuntu.com/security/CVE-2026-106552", "cve_description": "In sftp in OpenSSH before 10.6, a server can trigger directory traversal (causing files to be written to unintended locations) during a recursive copy operation.", "cve_priority": "medium", "cve_public_date": "2026-10-06 21:17:00 UTC" }, { "cve": "CVE-2026-106553", "url": "https://ubuntu.com/security/CVE-2026-106553", "cve_description": "In sshd in OpenSSH before 10.6, credentials can incorrectly persist after failure of a GSSAPIAuthentication authentication attempt.", "cve_priority": "medium", "cve_public_date": "2026-10-06 21:17:00 UTC" }, { "cve": "CVE-2026-106555", "url": "https://ubuntu.com/security/CVE-2026-106555", "cve_description": "In sshd in OpenSSH before 10.6, GSSAPIAuthentication authentication state can incorrectly be persisted across authentication attempts.", "cve_priority": "medium", "cve_public_date": "2026-10-06 21:17:00 UTC" }, { "cve": "CVE-2026-106582", "url": "https://ubuntu.com/security/CVE-2026-106582", "cve_description": "In sshd and ssh in OpenSSH before 10.6, an LZ77 dictionary coder can be used even though this is contraindicated by the arXiv 2609.07709 \"Crossing the Streams\" findings.", "cve_priority": "medium", "cve_public_date": "2026-10-06 21:17:00 UTC" }, { "cve": "CVE-2026-106583", "url": "https://ubuntu.com/security/CVE-2026-106583", "cve_description": "In ssh in OpenSSH before 10.6, a $ or \\ character can occur in a command-line username, leading to injection.", "cve_priority": "medium", "cve_public_date": "2026-10-07 00:17:00 UTC" }, { "cve": "CVE-2026-106584", "url": "https://ubuntu.com/security/CVE-2026-106584", "cve_description": "In ssh-keygen in OpenSSH before 10.6, certificates could have incorrect expiration times because of Daylight Saving mishandling. There can be a slightly more severe effect on users in certain Antarctic locations.", "cve_priority": "medium", "cve_public_date": "2026-10-06 21:17:00 UTC" }, { "cve": "CVE-2026-106585", "url": "https://ubuntu.com/security/CVE-2026-106585", "cve_description": "In sshd and ssh in OpenSSH before 10.6, there is no check for whether the maximum packet length is exceeded during decompression of highly compressed data.", "cve_priority": "medium", "cve_public_date": "2026-10-06 21:17:00 UTC" }, { "cve": "CVE-2026-106586", "url": "https://ubuntu.com/security/CVE-2026-106586", "cve_description": "In sshd in OpenSSH before 10.6, the restrict keyword (in authorized_keys) was supposed to be applicable to tunnel forwarding but was not, a different vulnerability than CVE-2026-73283.", "cve_priority": "medium", "cve_public_date": "2026-10-06 21:17:00 UTC" }, { "cve": "CVE-2026-106587", "url": "https://ubuntu.com/security/CVE-2026-106587", "cve_description": "In sshd in OpenSSH before 10.6, the value \"none\" for a configuration option is sometimes interpreted as a filename but was intended to mean that a feature is disabled.", "cve_priority": "medium", "cve_public_date": "2026-10-06 22:17:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: sftp directory traversal", " - debian/patches/CVE-2026-106552-pre1.patch: upstream: similar to scp, fix", " implicit destination path selection in sftp.c.", " - debian/patches/CVE-2026-106552.patch: upstream: sftp: be stricter in", " accepting paths returned by the in sftp-client.c, sftp.c.", " - CVE-2026-106552", " * SECURITY UPDATE: incorrect GSSAPIAuthentication auth persistence", " - debian/patches/CVE-2026-106553-1.patch: upstream: Reset GSSAPI client", " state before authentication in auth2.c, gss-serv.c, monitor.c, ssh-gss.h.", " - debian/patches/CVE-2026-106553-2.patch: upstream: Only store GSSAPI creds", " when authn succeeds in gss-serv.c, ssh-gss.h.", " - debian/patches/CVE-2026-106553-3.patch: upstream:", " ssh_gssapi_cleanup_global_client() needs a prototype in gss-serv.c, ssh-", " gss.h.", " - CVE-2026-106553", " - CVE-2026-106555", " * SECURITY UPDATE: incorrect use of LZ77 dictionary coder", " - debian/patches/CVE-2026-106582.patch: upstream: Disable LZ77 dictionary", " coder to avoid a potential in packet.c.", " - CVE-2026-106582", " * SECURITY UPDATE: invalid chars in command-line username", " - debian/patches/CVE-2026-106583-1.patch: upstream: Further restrict the", " characters allowed in a command-line in readconf.c.", " - debian/patches/CVE-2026-106583-2.patch: upstream: Add test for", " proxycommand percent expansions. in regress/percent.sh.", " - debian/patches/CVE-2026-106583-3.patch: avoid ksh-ism in regress test in", " regress/percent.sh.", " - CVE-2026-106583", " * SECURITY UPDATE: incorrect cert expiry in ssh-keygen", " - debian/patches/CVE-2026-106584.patch: upstream: Correct handling of DST", " when converting dates in misc.c.", " - CVE-2026-106584", " * SECURITY UPDATE: missing maximum packet length check", " - debian/patches/CVE-2026-106585.patch: upstream: Check that compressed", " payloads don't inflate beyond the in packet.c.", " - CVE-2026-106585", " * SECURITY UPDATE: incorrect restrict keyword usage in tunnel forwarding", " - debian/patches/CVE-2026-106586-1.patch: upstream: Propagate", " authorized_keys \"resrict\" keyword in auth-options.c.", " - debian/patches/CVE-2026-106586-2.patch: upstream: correctly check", " sshauthopt->restricted merging in regress/unittests/authopt/tests.c.", " - debian/patches/CVE-2026-106586-3.patch: upstream: simpler in", " regress/unittests/authopt/tests.c.", " - CVE-2026-106586", " * SECURITY UPDATE: \"none\" value confusion in options", " - debian/patches/CVE-2026-106587.patch: upstream: Correctly handle some", " options that accept \"none\" in servconf.c.", " - CVE-2026-106587", "" ], "package": "openssh", "version": "1:9.6p1-3ubuntu13.20", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Marc Deslauriers ", "date": "Thu, 08 Oct 2026 13:19:18 -0400" } ], "notes": null, "is_version_downgrade": false }, { "name": "openssh-sftp-server", "from_version": { "source_package_name": "openssh", "source_package_version": "1:9.6p1-3ubuntu13.19", "version": "1:9.6p1-3ubuntu13.19" }, "to_version": { "source_package_name": "openssh", "source_package_version": "1:9.6p1-3ubuntu13.20", "version": "1:9.6p1-3ubuntu13.20" }, "cves": [ { "cve": "CVE-2026-106552", "url": "https://ubuntu.com/security/CVE-2026-106552", "cve_description": "In sftp in OpenSSH before 10.6, a server can trigger directory traversal (causing files to be written to unintended locations) during a recursive copy operation.", "cve_priority": "medium", "cve_public_date": "2026-10-06 21:17:00 UTC" }, { "cve": "CVE-2026-106553", "url": "https://ubuntu.com/security/CVE-2026-106553", "cve_description": "In sshd in OpenSSH before 10.6, credentials can incorrectly persist after failure of a GSSAPIAuthentication authentication attempt.", "cve_priority": "medium", "cve_public_date": "2026-10-06 21:17:00 UTC" }, { "cve": "CVE-2026-106555", "url": "https://ubuntu.com/security/CVE-2026-106555", "cve_description": "In sshd in OpenSSH before 10.6, GSSAPIAuthentication authentication state can incorrectly be persisted across authentication attempts.", "cve_priority": "medium", "cve_public_date": "2026-10-06 21:17:00 UTC" }, { "cve": "CVE-2026-106582", "url": "https://ubuntu.com/security/CVE-2026-106582", "cve_description": "In sshd and ssh in OpenSSH before 10.6, an LZ77 dictionary coder can be used even though this is contraindicated by the arXiv 2609.07709 \"Crossing the Streams\" findings.", "cve_priority": "medium", "cve_public_date": "2026-10-06 21:17:00 UTC" }, { "cve": "CVE-2026-106583", "url": "https://ubuntu.com/security/CVE-2026-106583", "cve_description": "In ssh in OpenSSH before 10.6, a $ or \\ character can occur in a command-line username, leading to injection.", "cve_priority": "medium", "cve_public_date": "2026-10-07 00:17:00 UTC" }, { "cve": "CVE-2026-106584", "url": "https://ubuntu.com/security/CVE-2026-106584", "cve_description": "In ssh-keygen in OpenSSH before 10.6, certificates could have incorrect expiration times because of Daylight Saving mishandling. There can be a slightly more severe effect on users in certain Antarctic locations.", "cve_priority": "medium", "cve_public_date": "2026-10-06 21:17:00 UTC" }, { "cve": "CVE-2026-106585", "url": "https://ubuntu.com/security/CVE-2026-106585", "cve_description": "In sshd and ssh in OpenSSH before 10.6, there is no check for whether the maximum packet length is exceeded during decompression of highly compressed data.", "cve_priority": "medium", "cve_public_date": "2026-10-06 21:17:00 UTC" }, { "cve": "CVE-2026-106586", "url": "https://ubuntu.com/security/CVE-2026-106586", "cve_description": "In sshd in OpenSSH before 10.6, the restrict keyword (in authorized_keys) was supposed to be applicable to tunnel forwarding but was not, a different vulnerability than CVE-2026-73283.", "cve_priority": "medium", "cve_public_date": "2026-10-06 21:17:00 UTC" }, { "cve": "CVE-2026-106587", "url": "https://ubuntu.com/security/CVE-2026-106587", "cve_description": "In sshd in OpenSSH before 10.6, the value \"none\" for a configuration option is sometimes interpreted as a filename but was intended to mean that a feature is disabled.", "cve_priority": "medium", "cve_public_date": "2026-10-06 22:17:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-106552", "url": "https://ubuntu.com/security/CVE-2026-106552", "cve_description": "In sftp in OpenSSH before 10.6, a server can trigger directory traversal (causing files to be written to unintended locations) during a recursive copy operation.", "cve_priority": "medium", "cve_public_date": "2026-10-06 21:17:00 UTC" }, { "cve": "CVE-2026-106553", "url": "https://ubuntu.com/security/CVE-2026-106553", "cve_description": "In sshd in OpenSSH before 10.6, credentials can incorrectly persist after failure of a GSSAPIAuthentication authentication attempt.", "cve_priority": "medium", "cve_public_date": "2026-10-06 21:17:00 UTC" }, { "cve": "CVE-2026-106555", "url": "https://ubuntu.com/security/CVE-2026-106555", "cve_description": "In sshd in OpenSSH before 10.6, GSSAPIAuthentication authentication state can incorrectly be persisted across authentication attempts.", "cve_priority": "medium", "cve_public_date": "2026-10-06 21:17:00 UTC" }, { "cve": "CVE-2026-106582", "url": "https://ubuntu.com/security/CVE-2026-106582", "cve_description": "In sshd and ssh in OpenSSH before 10.6, an LZ77 dictionary coder can be used even though this is contraindicated by the arXiv 2609.07709 \"Crossing the Streams\" findings.", "cve_priority": "medium", "cve_public_date": "2026-10-06 21:17:00 UTC" }, { "cve": "CVE-2026-106583", "url": "https://ubuntu.com/security/CVE-2026-106583", "cve_description": "In ssh in OpenSSH before 10.6, a $ or \\ character can occur in a command-line username, leading to injection.", "cve_priority": "medium", "cve_public_date": "2026-10-07 00:17:00 UTC" }, { "cve": "CVE-2026-106584", "url": "https://ubuntu.com/security/CVE-2026-106584", "cve_description": "In ssh-keygen in OpenSSH before 10.6, certificates could have incorrect expiration times because of Daylight Saving mishandling. There can be a slightly more severe effect on users in certain Antarctic locations.", "cve_priority": "medium", "cve_public_date": "2026-10-06 21:17:00 UTC" }, { "cve": "CVE-2026-106585", "url": "https://ubuntu.com/security/CVE-2026-106585", "cve_description": "In sshd and ssh in OpenSSH before 10.6, there is no check for whether the maximum packet length is exceeded during decompression of highly compressed data.", "cve_priority": "medium", "cve_public_date": "2026-10-06 21:17:00 UTC" }, { "cve": "CVE-2026-106586", "url": "https://ubuntu.com/security/CVE-2026-106586", "cve_description": "In sshd in OpenSSH before 10.6, the restrict keyword (in authorized_keys) was supposed to be applicable to tunnel forwarding but was not, a different vulnerability than CVE-2026-73283.", "cve_priority": "medium", "cve_public_date": "2026-10-06 21:17:00 UTC" }, { "cve": "CVE-2026-106587", "url": "https://ubuntu.com/security/CVE-2026-106587", "cve_description": "In sshd in OpenSSH before 10.6, the value \"none\" for a configuration option is sometimes interpreted as a filename but was intended to mean that a feature is disabled.", "cve_priority": "medium", "cve_public_date": "2026-10-06 22:17:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: sftp directory traversal", " - debian/patches/CVE-2026-106552-pre1.patch: upstream: similar to scp, fix", " implicit destination path selection in sftp.c.", " - debian/patches/CVE-2026-106552.patch: upstream: sftp: be stricter in", " accepting paths returned by the in sftp-client.c, sftp.c.", " - CVE-2026-106552", " * SECURITY UPDATE: incorrect GSSAPIAuthentication auth persistence", " - debian/patches/CVE-2026-106553-1.patch: upstream: Reset GSSAPI client", " state before authentication in auth2.c, gss-serv.c, monitor.c, ssh-gss.h.", " - debian/patches/CVE-2026-106553-2.patch: upstream: Only store GSSAPI creds", " when authn succeeds in gss-serv.c, ssh-gss.h.", " - debian/patches/CVE-2026-106553-3.patch: upstream:", " ssh_gssapi_cleanup_global_client() needs a prototype in gss-serv.c, ssh-", " gss.h.", " - CVE-2026-106553", " - CVE-2026-106555", " * SECURITY UPDATE: incorrect use of LZ77 dictionary coder", " - debian/patches/CVE-2026-106582.patch: upstream: Disable LZ77 dictionary", " coder to avoid a potential in packet.c.", " - CVE-2026-106582", " * SECURITY UPDATE: invalid chars in command-line username", " - debian/patches/CVE-2026-106583-1.patch: upstream: Further restrict the", " characters allowed in a command-line in readconf.c.", " - debian/patches/CVE-2026-106583-2.patch: upstream: Add test for", " proxycommand percent expansions. in regress/percent.sh.", " - debian/patches/CVE-2026-106583-3.patch: avoid ksh-ism in regress test in", " regress/percent.sh.", " - CVE-2026-106583", " * SECURITY UPDATE: incorrect cert expiry in ssh-keygen", " - debian/patches/CVE-2026-106584.patch: upstream: Correct handling of DST", " when converting dates in misc.c.", " - CVE-2026-106584", " * SECURITY UPDATE: missing maximum packet length check", " - debian/patches/CVE-2026-106585.patch: upstream: Check that compressed", " payloads don't inflate beyond the in packet.c.", " - CVE-2026-106585", " * SECURITY UPDATE: incorrect restrict keyword usage in tunnel forwarding", " - debian/patches/CVE-2026-106586-1.patch: upstream: Propagate", " authorized_keys \"resrict\" keyword in auth-options.c.", " - debian/patches/CVE-2026-106586-2.patch: upstream: correctly check", " sshauthopt->restricted merging in regress/unittests/authopt/tests.c.", " - debian/patches/CVE-2026-106586-3.patch: upstream: simpler in", " regress/unittests/authopt/tests.c.", " - CVE-2026-106586", " * SECURITY UPDATE: \"none\" value confusion in options", " - debian/patches/CVE-2026-106587.patch: upstream: Correctly handle some", " options that accept \"none\" in servconf.c.", " - CVE-2026-106587", "" ], "package": "openssh", "version": "1:9.6p1-3ubuntu13.20", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Marc Deslauriers ", "date": "Thu, 08 Oct 2026 13:19:18 -0400" } ], "notes": null, "is_version_downgrade": false }, { "name": "python3-jwt", "from_version": { "source_package_name": "pyjwt", "source_package_version": "2.7.0-1ubuntu0.2", "version": "2.7.0-1ubuntu0.2" }, "to_version": { "source_package_name": "pyjwt", "source_package_version": "2.7.0-1ubuntu0.3", "version": "2.7.0-1ubuntu0.3" }, "cves": [ { "cve": "CVE-2026-102267", "url": "https://ubuntu.com/security/CVE-2026-102267", "cve_description": "PyJWT is a Python implementation of JSON Web Token standards. Prior to 2.14.0, PyJWT PyJWKClient is affected because redirect destinations are not revalidated against the JWKS trust boundary. This occurs when a configured trusted JWKS endpoint returns an attacker-influenced redirect. As a result, PyJWKClient follows the redirect and consumes the redirected response as key material. Consequently, forwarded credentials may be disclosed or verification keys may be substituted. This issue is fixed in version 2.14.0.", "cve_priority": "medium", "cve_public_date": "2026-09-28 21:17:00 UTC" }, { "cve": "CVE-2026-102268", "url": "https://ubuntu.com/security/CVE-2026-102268", "cve_description": "PyJWT is a Python implementation of JSON Web Token standards. Prior to 2.14.0, is_pem_format in jwt/utils.py is affected because is_pem_format does not recognize every PEM representation accepted by the cryptography loader. This occurs when an application mixes HMAC and asymmetric algorithms and supplies a mutated public-key PEM as raw key bytes. As a result, HMACAlgorithm.prepare_key treats the unrecognized asymmetric public key as an HMAC secret. Consequently, an attacker who knows the public key can forge authenticated HMAC tokens. This issue is fixed in version 2.14.0.", "cve_priority": "medium", "cve_public_date": "2026-09-28 21:17:00 UTC" }, { "cve": "CVE-2026-102271", "url": "https://ubuntu.com/security/CVE-2026-102271", "cve_description": "PyJWT is a Python implementation of JSON Web Token standards. From 2.4.0 until 2.14.0, PyJWT HMACAlgorithm.prepare_key is affected because asymmetric-key guard relies on textual markers that are absent from DER encoding. This occurs when an application mixes HMAC and asymmetric algorithms and supplies a DER public key as the shared verification key. As a result, PyJWT uses public DER bytes as an HMAC secret. Consequently, an attacker who knows the public key can forge authenticated HMAC tokens. This issue is fixed in version 2.14.0.", "cve_priority": "medium", "cve_public_date": "2026-09-28 21:17:00 UTC" }, { "cve": "CVE-2026-102272", "url": "https://ubuntu.com/security/CVE-2026-102272", "cve_description": "PyJWT is a Python implementation of JSON Web Token standards. From 2.13.0 until 2.14.0, HMACAlgorithm.prepare_key in jwt/algorithms.py is affected because raw-JWK detector does not normalize accepted Unicode byte-order marks before checking for JSON. This occurs when a public JWK is prefixed with a UTF-8 BOM and used in a mixed-algorithm verification path. As a result, public JWK bypasses asymmetric-key detection and becomes the HMAC secret. Consequently, an attacker who knows the public key can forge authenticated tokens. This issue is fixed in version 2.14.0.", "cve_priority": "medium", "cve_public_date": "2026-09-28 21:17:00 UTC" }, { "cve": "CVE-2026-102273", "url": "https://ubuntu.com/security/CVE-2026-102273", "cve_description": "PyJWT is a Python implementation of JSON Web Token standards. From 2.13.0 until 2.14.0, PyJWT HMACAlgorithm.prepare_key is affected because HMAC key guard only recognizes top-level public JWK forms and misses container representations. This occurs when an application allows HMAC and asymmetric algorithms and passes a public JWK container as the raw key. As a result, public asymmetric key material is accepted as the HMAC secret. Consequently, an attacker who knows the public key can forge a token with arbitrary authenticated claims. This issue is fixed in version 2.14.0.", "cve_priority": "medium", "cve_public_date": "2026-09-28 21:17:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-102267", "url": "https://ubuntu.com/security/CVE-2026-102267", "cve_description": "PyJWT is a Python implementation of JSON Web Token standards. Prior to 2.14.0, PyJWT PyJWKClient is affected because redirect destinations are not revalidated against the JWKS trust boundary. This occurs when a configured trusted JWKS endpoint returns an attacker-influenced redirect. As a result, PyJWKClient follows the redirect and consumes the redirected response as key material. Consequently, forwarded credentials may be disclosed or verification keys may be substituted. This issue is fixed in version 2.14.0.", "cve_priority": "medium", "cve_public_date": "2026-09-28 21:17:00 UTC" }, { "cve": "CVE-2026-102268", "url": "https://ubuntu.com/security/CVE-2026-102268", "cve_description": "PyJWT is a Python implementation of JSON Web Token standards. Prior to 2.14.0, is_pem_format in jwt/utils.py is affected because is_pem_format does not recognize every PEM representation accepted by the cryptography loader. This occurs when an application mixes HMAC and asymmetric algorithms and supplies a mutated public-key PEM as raw key bytes. As a result, HMACAlgorithm.prepare_key treats the unrecognized asymmetric public key as an HMAC secret. Consequently, an attacker who knows the public key can forge authenticated HMAC tokens. This issue is fixed in version 2.14.0.", "cve_priority": "medium", "cve_public_date": "2026-09-28 21:17:00 UTC" }, { "cve": "CVE-2026-102271", "url": "https://ubuntu.com/security/CVE-2026-102271", "cve_description": "PyJWT is a Python implementation of JSON Web Token standards. From 2.4.0 until 2.14.0, PyJWT HMACAlgorithm.prepare_key is affected because asymmetric-key guard relies on textual markers that are absent from DER encoding. This occurs when an application mixes HMAC and asymmetric algorithms and supplies a DER public key as the shared verification key. As a result, PyJWT uses public DER bytes as an HMAC secret. Consequently, an attacker who knows the public key can forge authenticated HMAC tokens. This issue is fixed in version 2.14.0.", "cve_priority": "medium", "cve_public_date": "2026-09-28 21:17:00 UTC" }, { "cve": "CVE-2026-102272", "url": "https://ubuntu.com/security/CVE-2026-102272", "cve_description": "PyJWT is a Python implementation of JSON Web Token standards. From 2.13.0 until 2.14.0, HMACAlgorithm.prepare_key in jwt/algorithms.py is affected because raw-JWK detector does not normalize accepted Unicode byte-order marks before checking for JSON. This occurs when a public JWK is prefixed with a UTF-8 BOM and used in a mixed-algorithm verification path. As a result, public JWK bypasses asymmetric-key detection and becomes the HMAC secret. Consequently, an attacker who knows the public key can forge authenticated tokens. This issue is fixed in version 2.14.0.", "cve_priority": "medium", "cve_public_date": "2026-09-28 21:17:00 UTC" }, { "cve": "CVE-2026-102273", "url": "https://ubuntu.com/security/CVE-2026-102273", "cve_description": "PyJWT is a Python implementation of JSON Web Token standards. From 2.13.0 until 2.14.0, PyJWT HMACAlgorithm.prepare_key is affected because HMAC key guard only recognizes top-level public JWK forms and misses container representations. This occurs when an application allows HMAC and asymmetric algorithms and passes a public JWK container as the raw key. As a result, public asymmetric key material is accepted as the HMAC secret. Consequently, an attacker who knows the public key can forge a token with arbitrary authenticated claims. This issue is fixed in version 2.14.0.", "cve_priority": "medium", "cve_public_date": "2026-09-28 21:17:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: Unvalidated HTTP redirect traversal in PyJWKClient", " - debian/patches/CVE-2026-102267.patch: Reject redirects in PyJWKClient", " fetches in jwt/jwks_client.py, tests/test_jwks_client.py.", " - CVE-2026-102267", " * SECURITY UPDATE: Algorithm confusion via whitespace and line-break evasion", " in is_pem_format", " - debian/patches/CVE-2026-102268.patch: fix: reject loader-accepted PEM", " variants in jwt/utils.py, tests/test_algorithms.py.", " - CVE-2026-102268", " * SECURITY UPDATE: Algorithm confusion via DER-encoded public key bytes in ", " HMACAlgorithm.prepare_key", " - debian/patches/CVE-2026-102271.patch: fix: reject DER public keys as ", " HMAC secrets in jwt/algorithms.py, tests/test_algorithms.py.", " - CVE-2026-102271", " * SECURITY UPDATE: Key inspection bypass via UTF-8 Byte Order Mark (BOM) in", " HMACAlgorithm.prepare_key", " - debian/patches/CVE-2026-102272.patch: Reject encoded JWKs as HMAC keys", " in jwt/algorithms.py, tests/test_algorithms.py.", " - CVE-2026-102272", " * SECURITY UPDATE: Key-type spoofing via nested JWK container structures in ", " HMACAlgorithm.prepare_key", " - debian/patches/CVE-2026-102273.patch: fix: reject public JWK container", " HMAC keys in jwt/algorithms.py, tests/test_algorithms.py.", " - CVE-2026-102273", "" ], "package": "pyjwt", "version": "2.7.0-1ubuntu0.3", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Hurman ", "date": "Thu, 08 Oct 2026 15:21:26 +0800" } ], "notes": null, "is_version_downgrade": false }, { "name": "python3-urllib3", "from_version": { "source_package_name": "python-urllib3", "source_package_version": "2.0.7-1ubuntu0.7", "version": "2.0.7-1ubuntu0.7" }, "to_version": { "source_package_name": "python-urllib3", "source_package_version": "2.0.7-1ubuntu0.8", "version": "2.0.7-1ubuntu0.8" }, "cves": [ { "cve": "CVE-2026-97688", "url": "https://ubuntu.com/security/CVE-2026-97688", "cve_description": "urllib3 is an HTTP client library for Python. From 2.6.2 until 2.8.0, HTTPResponse.stream and HTTPResponse.read_chunked can enter an infinite loop because the Deflate decoder retains trailing bytes as unconsumed input after reaching end-of-stream and repeatedly decodes them without progress. The issue occurs when an untrusted server sends a chunked Deflate response whose decoded body exceeds a positive finite chunk size and whose encoded body has trailing bytes, specifically a response with Transfer-Encoding: chunked and Content-Encoding: deflate, content decoding enabled, and the positive finite amt=N streaming chunk size. The attack mechanism is that a malicious server returns a compressed chunked response with trailing bytes after the Deflate stream. The impact is excessive CPU usage and a request that does not complete, and network read timeouts do not interrupt the loop because no further socket read occurs. This issue is fixed in version 2.8.0.", "cve_priority": "medium", "cve_public_date": "2026-09-29 16:17:00 UTC" }, { "cve": "CVE-2026-97689", "url": "https://ubuntu.com/security/CVE-2026-97689", "cve_description": "urllib3 is an HTTP client library for Python. From 1.10.3 until 2.8.0, the HTTPResponse.read_chunked and HTTPResponse.stream methods can allocate unbounded memory because the streaming chunk parser buffers the chunk-size field until newline or EOF without a length bound. The trigger is that a malicious server returns Transfer-Encoding: chunked followed by a very long run of bytes without a newline. The attack mechanism is that a malicious HTTP server sends a very long unterminated chunk-size line. The impact is that unbounded memory allocation can exhaust the client process. This issue is fixed in version 2.8.0.", "cve_priority": "medium", "cve_public_date": "2026-09-29 16:17:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2026-97688", "url": "https://ubuntu.com/security/CVE-2026-97688", "cve_description": "urllib3 is an HTTP client library for Python. From 2.6.2 until 2.8.0, HTTPResponse.stream and HTTPResponse.read_chunked can enter an infinite loop because the Deflate decoder retains trailing bytes as unconsumed input after reaching end-of-stream and repeatedly decodes them without progress. The issue occurs when an untrusted server sends a chunked Deflate response whose decoded body exceeds a positive finite chunk size and whose encoded body has trailing bytes, specifically a response with Transfer-Encoding: chunked and Content-Encoding: deflate, content decoding enabled, and the positive finite amt=N streaming chunk size. The attack mechanism is that a malicious server returns a compressed chunked response with trailing bytes after the Deflate stream. The impact is excessive CPU usage and a request that does not complete, and network read timeouts do not interrupt the loop because no further socket read occurs. This issue is fixed in version 2.8.0.", "cve_priority": "medium", "cve_public_date": "2026-09-29 16:17:00 UTC" }, { "cve": "CVE-2026-97689", "url": "https://ubuntu.com/security/CVE-2026-97689", "cve_description": "urllib3 is an HTTP client library for Python. From 1.10.3 until 2.8.0, the HTTPResponse.read_chunked and HTTPResponse.stream methods can allocate unbounded memory because the streaming chunk parser buffers the chunk-size field until newline or EOF without a length bound. The trigger is that a malicious server returns Transfer-Encoding: chunked followed by a very long run of bytes without a newline. The attack mechanism is that a malicious HTTP server sends a very long unterminated chunk-size line. The impact is that unbounded memory allocation can exhaust the client process. This issue is fixed in version 2.8.0.", "cve_priority": "medium", "cve_public_date": "2026-09-29 16:17:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: Denial of Service", " - debian/patches/CVE-2026-97688.patch: Prevent an infinite loop", " when decoding Deflate responses", " - debian/patches/CVE-2026-97689.patch: Bound chunk-size line reads", " to prevent memory exhaustion DoS", " - CVE-2026-97688", " - CVE-2026-97689", "" ], "package": "python-urllib3", "version": "2.0.7-1ubuntu0.8", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [], "author": "Bruce Cable ", "date": "Tue, 13 Oct 2026 13:55:12 +1100" } ], "notes": null, "is_version_downgrade": false }, { "name": "snapd", "from_version": { "source_package_name": "snapd", "source_package_version": "2.76.3+ubuntu24.04", "version": "2.76.3+ubuntu24.04" }, "to_version": { "source_package_name": "snapd", "source_package_version": "2.77.1+ubuntu24.04", "version": "2.77.1+ubuntu24.04" }, "cves": [ { "cve": "CVE-2024-5300", "url": "https://ubuntu.com/security/CVE-2024-5300", "cve_description": "An access control bypass and information disclosure vulnerability exists in the base AppArmor security profile configuration of Canonical snapd. The abstraction rules located in /etc/apparmor.d/abstractions/nss-systemd (inherited via ) inadvertently permit strictly confined snap applications, which lack the privileged account-control interface, to interact directly with the io.systemd.Multiplexer and io.systemd.NameServiceSwitch UNIX domain sockets under /run/systemd/userdb/. On systems where the systemd-userdbd service is installed and operational, the service fails to distinguish between an unconfined root user on the host system and a restricted root user running within a snap application's sandbox (such as a daemon or configuration hook). Because systemd-userdbd returns \"complete\" user records—including sensitive hashed user passwords from /etc/shadow—when queried by a process running as root, a compromised or malicious strictly confined snap executing code as root can successfully query the Varlink interface to retrieve all system password hashes, bypassing intended snap sandbox restrictions. This issue is mitigated by the fact that systemd-userdbd is not installed by default on standard Ubuntu deployments.", "cve_priority": "medium", "cve_public_date": "2026-07-21 15:16:00 UTC" }, { "cve": "CVE-2026-3888", "url": "https://ubuntu.com/security/CVE-2026-3888", "cve_description": "Local privilege escalation in snapd on Linux allows local attackers to get root privilege by re-creating snap's private /tmp directory when systemd-tmpfiles is configured to automatically clean up this directory. This issue affects Ubuntu 16.04 LTS, 18.04 LTS, 20.04 LTS, 22.04 LTS, and 24.04 LTS.", "cve_priority": "high", "cve_public_date": "2026-03-17 14:16:00 UTC" }, { "cve": "CVE-2024-5300", "url": "https://ubuntu.com/security/CVE-2024-5300", "cve_description": "An access control bypass and information disclosure vulnerability exists in the base AppArmor security profile configuration of Canonical snapd. The abstraction rules located in /etc/apparmor.d/abstractions/nss-systemd (inherited via ) inadvertently permit strictly confined snap applications, which lack the privileged account-control interface, to interact directly with the io.systemd.Multiplexer and io.systemd.NameServiceSwitch UNIX domain sockets under /run/systemd/userdb/. On systems where the systemd-userdbd service is installed and operational, the service fails to distinguish between an unconfined root user on the host system and a restricted root user running within a snap application's sandbox (such as a daemon or configuration hook). Because systemd-userdbd returns \"complete\" user records—including sensitive hashed user passwords from /etc/shadow—when queried by a process running as root, a compromised or malicious strictly confined snap executing code as root can successfully query the Varlink interface to retrieve all system password hashes, bypassing intended snap sandbox restrictions. This issue is mitigated by the fact that systemd-userdbd is not installed by default on standard Ubuntu deployments.", "cve_priority": "medium", "cve_public_date": "2026-07-21 15:16:00 UTC" }, { "cve": "CVE-2026-3888", "url": "https://ubuntu.com/security/CVE-2026-3888", "cve_description": "Local privilege escalation in snapd on Linux allows local attackers to get root privilege by re-creating snap's private /tmp directory when systemd-tmpfiles is configured to automatically clean up this directory. This issue affects Ubuntu 16.04 LTS, 18.04 LTS, 20.04 LTS, 22.04 LTS, and 24.04 LTS.", "cve_priority": "high", "cve_public_date": "2026-03-17 14:16:00 UTC" } ], "launchpad_bugs_fixed": [ 2158102, 2072331, 2110510, 2143934, 2160691, 2161982, 2158301, 2159940, 2157692, 2067006, 2157692, 2067006, 2154498, 2147606, 2148544, 2139213, 2125344, 2150683, 2152908, 1966067, 2110368, 2110368, 2144666, 2146337, 2147207, 2143882 ], "changes": [ { "cves": [], "log": [ "", " * New upstream release, LP: #2158102", " - Fix undo of unlink-component after its snap revision was discarded", " - interfaces: power-control | allow reading all battery state files", "" ], "package": "snapd", "version": "2.77.1+ubuntu24.04", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2158102 ], "author": "Ernest Lotter ", "date": "Wed, 02 Sep 2026 14:39:12 +0200" }, { "cves": [], "log": [ "", " - Account for differences in names of the binaries in the snapd FIPS", " build", " - Add code to calculate canonical subject name hash", " - Add commands for debugging or accessing snap mount namespaces", " - Add helpers for listing and iterating device mediation groups", " - Add package ebpf with helpers wrapping eBPF exposed objects with", " dependency on github.com/cilium/ebpf", " - Add secondary prerequisites task that acts as the synchronization", " point, which ensures that a snap's prerequisites are available", " before it's installed", " - Add support for shell conditional syntax in envs", " - Added /usr/share/{man,help,info} to system-packages-doc", " - asserts: add validation-sets confdb-schema builtin", " - asserts: ensure that compatibility labels are strings", " - asserts: extend on-classic constraints to accept \"distro/variant\",", " \"distro/*\", and \"distro/\" under a new snap-declaration format 7", " - asserts: validate serial in newDeviceIDFromString", " - Bump github.com/canonical/go-efilib to v1.8.0 to include fixes for", " efivars probe", " - confdb: add validation-sets handler and fix data loss when writing", " to new schemas or accounts", " - confdb: fix bug on reading uneven lists", " - confdb: literal subkeys are sorted after placeholders", " - confdb: run observe-view-* hooks after commit", " - confdb: support Encode/Decode for builtins", " - confdb: support sign-only external keypair backends", " - core-initrd: add missing libbpf and systemd dlopen dependencies,", " and increase mount burst", " - Drop task logs for delayed effects", " - During snap removal, clear-snap task errors early if there are", " user mounts in snap data dirs", " - Enable reverts to trigger a seed refresh", " - Ensure profiles are setup before running prepare-{slot, plug}*", " hooks", " - Ensure that prereqs created by initial refresh run before create-", " recovery-system", " - Exclude Georgian from translation linting", " - experimental features: graduate layouts, classic-preserves-xdg-", " runtime-dir, refresh-app-awareness, and dbus-activation features", " - experimental features: warn when setting graduated or default-", " enabled experimental features and do not store settings for", " graduated features", " - Expose individual certs as well as c_rehash emulation", " - Extend autogen with explicit --sysconfdir", " - External keypair manager: add shared external key manager", " implementation", " - External keypair manager: refactor GPG and external keypair", " managers to use extKeypairMgrImpl", " - External keypair manager: support external OPENPGP signing in", " ExternalKeypairManager", " - FDE: add post install actions API", " - FDE: add reprovision API", " - FDE: add reprovision recovery key generation API", " - FDE: add reseal check after snapd refresh", " - FDE: allow reprovision without factory reset", " - FDE: change makebootable part of the boot package to not take", " install observers as parameters", " - FDE: extend storage-encrypted system information", " - FDE: make reprovision only seal", " - FDE: remove all tmp keyslots on error", " - FDE: remove check for unchanged authentication options", " - FDE: run post install checks during auto repair", " - Filter seed-refresh based on model and seed presence", " - Fix failing snap remove when there are snapctl created mounts", " under snap global data dirs", " - Fix postNotices to validate before locking state", " - Guard the ensure check from running on classic", " - Implement remodeling fully in terms of updates", " - Implement ShutDown for HookManager", " - Include variables SNAP_APP_NAME, and when applicable", " SNAP_APP_COMMON_ID, SNAP_APP_DESKTOP_FILE and SNAP_APP_BUS_NAME in", " snap application environments", " - interfaces: add xdg-portal-permission-store interface", " - interfaces: allow gtk css in subdirectories", " - interfaces: allow systemd networkd link property changes via D-Bus", " - interfaces: allow the systemd networkctl command", " - interfaces: allow Wine to execute files accessed via the Document", " Portal", " - interfaces: apparmor-observe | add interface", " - interfaces: attempt to fix content with parallel installs", " - interfaces: devlxd | fix access for LXD containers", " - interfaces: docker | allow connecting to system-wide docker on", " classic", " - interfaces: grant default access to memory.high in a snap's cgroup", " - interfaces: iscsi-initiator | allow access to /var/lib/iscsi/nodes", " - interfaces: kernel-sched-ext-control | add the kernel sched-ext", " control interface implementation", " - interfaces: make polkit and upower implicit on Core systems only", " - interfaces: open-iscsi | add missing state paths", " - interfaces: opengl | expose wsl libraries", " - interfaces: u2f-devices | add atkey PID and relative VID support", " - List dir contents on failure to remove snap base data dir", " - List non-snapctl mounts in snap data dirs", " - LP: #2072331 Validate map keys in JSON config values", " - LP: #2110510 Interfaces: allow reading of /proc/self/smaps_rollup", " - LP: #2143934 Interfaces: network-control, network-manager | allow", " missing resolve1 link setters", " - LP: #2160691 Security logging: strip trailing whitespace from", " audit netlink message payload", " - LP: #2161982 Interfaces: vsock | add interface for VM guest", " services", " - Make arguments of debug mount-namespace consistent with other", " debug commands", " - Make bootloader logging less verbose", " - Make cert manager garbage check run after symlink migration", " - Make secondary prerequisite synchronization task handle same-", " change retries", " - mkversion.sh: do describe in worktrees too", " - multi-entry snapd: merge snap and snapd binaries", " - multi-entry snapd: move debug device-cgroup implementation file", " under cmd/snapd/cli", " - multi-entry snapd: move snap-gpio-helper sources around before", " transitioning to multi-entry dispatch", " - multi-entry snapd: move snapd-apparmor sources to a dedicated tool", " location", " - multi-entry snapd: move source files around in preparation for", " snapd/snap merge", " - multi-entry snapd: move the snap-preseed sources around in", " preparation", " - multi-entry snapd: move the sources of snapctl and snap-exec in", " preparation for the multi-entry dispatch", " - Never create seed refresh tasks during a remodel", " - packaging: assign a default label for /tmp/snap-private-tmp and", " set it during installation", " - packaging: build deb with Go 1.23 for noble and jammy, Go 1.22 for", " focal", " - packaging: drop SNAP_TAGS", " - packaging: drop symlinks for opensuse 15.5/15.6 packaging", " - packaging: fix service startup during install and session-agent", " socket handling on Ubuntu 26.04+", " - packaging: fix stderr redirection", " - packaging: restore gbp.conf output directory for Ubuntu 26.04", " builds", " - packaging: switch to apparmor 5.x with 5 ABI", " - packaging: update bundled AppArmor to 5.0.2 and accept the 5.0 ABI", " when running as deb", " - packaging: use a relative symlink for snapctl and update steam-", " support udev rules", " - Preserve component in hook security tags", " - Prevent removal of seed-refresh snaps when seed-refresh is enabled", " - Refactor base-declaration into 1st class builtin assertion", " - Refactor how the is-originating-from-snap-command advisory check", " works", " - Refactor prerequisites task handler to enable proper seed-refresh", " integration", " - Reintroduce fdstore helpers", " - remote device management: add task to validate request messages", " - remote device management: apply management messages, queue", " response messages, and improve sequencing and redelivery handling", " - Remove osutil unused AtomicWriteFollow flag", " - Remove xerrors dependency", " - Reuse existing seed-refresh implementation for free during single-", " path installation", " - Rework how SnapSetup.SnapPath is used", " - seccomp: allow rseq_slice_yield", " - security logging: add seclog API for administrative actions and", " token create/remove events", " - security logging: add security logging for adding, updating and", " removing a snapd user", " - Set target hostname from install-mode", " - snap-confine: improve loading of BPF programs, retry on failures", " to collect verifier logs", " - snap-confine: use profile and flags= in snap-confine and snap-", " update-ns' AppArmor profiles", " - snap-confine: work around kernel mnt_ns_loop() ordering bug on", " 6.18.x", " - snap: add debug command for listing currently mediated devices for", " a given snap", " - snap: fix self-managed cgroup support checks", " - snap: report hidden file access for paths allowed by home when", " prompting is active", " - snap: report read-only file access for paths allowed by system-", " package-doc", " - snapctl async support: add --format json to snap tasks to be", " consistent with snapctl", " - snapctl async support: add snapctl tasks command", " - snapctl async support: async feature negotiation between snap", " client and daemon", " - snapctl async support: fix snapctl is-ready exit codes", " - snapctl async support: re-enable snapctl async functionality", " - snapshots: restore preserves snapctl created mounts", " - snapshots: save excludes all mount points", " - Support ca-certificate.crt only systems like core26", " - Turn on quota-groups by default", " - Use 0755 for certificate generation directories", " - Use CreateTemp for NewAtomicFile tmp file creation", " - Verify cached downloads in the do path and detect obvious", " corruption", "" ], "package": "snapd", "version": "2.77+ubuntu24.04", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2072331, 2110510, 2143934, 2160691, 2161982 ], "author": "Sergio Cazzolato ", "date": "Fri, 24 Jul 2026 20:45:05 -0300" }, { "cves": [], "log": [ "", " * New upstream release, LP: #2158301", " - FDE: support keyboard configuration at install-time for first-boot", " - FDE: re-enable passphrases/PINs at install-time", " - FDE: require volumes authentication if HWROT is missing", " - FDE: bump secboot to rev 457b03a16d19", " - FDE: use new secboot API for reprovision TPM", " - Cross-distro: modify SELinux policy to use", " init_named_socket_activation() for allowing systemd to start snapd", " through socket activation", " - packaging: make sure that usr/bin/snap is built with correct build", " tags on debian sid", " - Ensure profiles are setup before running prepare-{slot, plug}*", " hooks", "" ], "package": "snapd", "version": "2.76.3", "urgency": "medium", "distributions": "xenial", "launchpad_bugs_fixed": [ 2158301 ], "author": "Katie May ", "date": "Tue, 07 Jul 2026 10:06:48 +0200" }, { "cves": [], "log": [ "", " * New upstream release, LP: #2159940", " - interfaces: steam-support, docker-support | fix mountinfo denial", "" ], "package": "snapd", "version": "2.76.2", "urgency": "medium", "distributions": "xenial", "launchpad_bugs_fixed": [ 2159940 ], "author": "Katie May ", "date": "Tue, 07 Jul 2026 08:38:51 +0200" }, { "cves": [ { "cve": "CVE-2024-5300", "url": "https://ubuntu.com/security/CVE-2024-5300", "cve_description": "An access control bypass and information disclosure vulnerability exists in the base AppArmor security profile configuration of Canonical snapd. The abstraction rules located in /etc/apparmor.d/abstractions/nss-systemd (inherited via ) inadvertently permit strictly confined snap applications, which lack the privileged account-control interface, to interact directly with the io.systemd.Multiplexer and io.systemd.NameServiceSwitch UNIX domain sockets under /run/systemd/userdb/. On systems where the systemd-userdbd service is installed and operational, the service fails to distinguish between an unconfined root user on the host system and a restricted root user running within a snap application's sandbox (such as a daemon or configuration hook). Because systemd-userdbd returns \"complete\" user records—including sensitive hashed user passwords from /etc/shadow—when queried by a process running as root, a compromised or malicious strictly confined snap executing code as root can successfully query the Varlink interface to retrieve all system password hashes, bypassing intended snap sandbox restrictions. This issue is mitigated by the fact that systemd-userdbd is not installed by default on standard Ubuntu deployments.", "cve_priority": "medium", "cve_public_date": "2026-07-21 15:16:00 UTC" }, { "cve": "CVE-2026-3888", "url": "https://ubuntu.com/security/CVE-2026-3888", "cve_description": "Local privilege escalation in snapd on Linux allows local attackers to get root privilege by re-creating snap's private /tmp directory when systemd-tmpfiles is configured to automatically clean up this directory. This issue affects Ubuntu 16.04 LTS, 18.04 LTS, 20.04 LTS, 22.04 LTS, and 24.04 LTS.", "cve_priority": "high", "cve_public_date": "2026-03-17 14:16:00 UTC" } ], "log": [ "", " * New upstream release, LP: #2157692", " - LP: #2067006 CVE-2024-5300", " - CVE-2026-3888", "" ], "package": "snapd", "version": "2.76.1", "urgency": "medium", "distributions": "xenial", "launchpad_bugs_fixed": [ 2157692, 2067006 ], "author": "Ernest Lotter ", "date": "Thu, 25 Jun 2026 13:09:05 +0200" }, { "cves": [ { "cve": "CVE-2024-5300", "url": "https://ubuntu.com/security/CVE-2024-5300", "cve_description": "An access control bypass and information disclosure vulnerability exists in the base AppArmor security profile configuration of Canonical snapd. The abstraction rules located in /etc/apparmor.d/abstractions/nss-systemd (inherited via ) inadvertently permit strictly confined snap applications, which lack the privileged account-control interface, to interact directly with the io.systemd.Multiplexer and io.systemd.NameServiceSwitch UNIX domain sockets under /run/systemd/userdb/. On systems where the systemd-userdbd service is installed and operational, the service fails to distinguish between an unconfined root user on the host system and a restricted root user running within a snap application's sandbox (such as a daemon or configuration hook). Because systemd-userdbd returns \"complete\" user records—including sensitive hashed user passwords from /etc/shadow—when queried by a process running as root, a compromised or malicious strictly confined snap executing code as root can successfully query the Varlink interface to retrieve all system password hashes, bypassing intended snap sandbox restrictions. This issue is mitigated by the fact that systemd-userdbd is not installed by default on standard Ubuntu deployments.", "cve_priority": "medium", "cve_public_date": "2026-07-21 15:16:00 UTC" }, { "cve": "CVE-2026-3888", "url": "https://ubuntu.com/security/CVE-2026-3888", "cve_description": "Local privilege escalation in snapd on Linux allows local attackers to get root privilege by re-creating snap's private /tmp directory when systemd-tmpfiles is configured to automatically clean up this directory. This issue affects Ubuntu 16.04 LTS, 18.04 LTS, 20.04 LTS, 22.04 LTS, and 24.04 LTS.", "cve_priority": "high", "cve_public_date": "2026-03-17 14:16:00 UTC" } ], "log": [ "", " * New upstream release, LP: #2157692", " - LP: #2067006 CVE-2024-5300", " - CVE-2026-3888", " - SNAPDENG-36017", "" ], "package": "snapd", "version": "2.76.1", "urgency": "medium", "distributions": "xenial", "launchpad_bugs_fixed": [ 2157692, 2067006 ], "author": "Ernest Lotter ", "date": "Sat, 20 Jun 2026 10:27:54 +0200" }, { "cves": [], "log": [ "", " * New upstream release, LP: #2154498", " - assertions: add helper for validating integrity data", " - assertions: drop incorrect/non-standard Ed25519 support", " - confdb: allow only API admin read access to confdb secrets", " - confdb: block concurrent confdb accesses", " - confdb: block concurrent snapctl accesses to configuration", " database", " - confdb: check for ephemeral data when missing save-view hook on", " commit", " - confdb: ignore not-found errors in confdb-schema refreshes", " - confdb: support --wait-for timeouts when accessing confdb", " - core-initrd: add group referenced in udev rules", " - core-initrd: add libbpf dependency to initramfs", " - core-initrd: add missing libbpf dependency in 24.04 packaging", " - core-initrd: ensure audio is a system group", " - core-initrd: fix /boot/uboot mount with u-boot env in dedicated", " partition", " - core-initrd: increase mount burst from 5 to 128 for faster boot", " - core-initrd: sync partition udev rules with the ones in core-base", " - core-initrd: sync with latest upload to snappy-dev PPA", " - core-initrd: synchronize changelogs with latest PPA upload", " - core-initrd: update changelog with latest PPA upload", " - core-initrd: add nfnetlink module to fix nf netlink", " socket speed regression (Ubuntu Core only)", " - cross-distro: allow snapd to manipulate systemd unit files in", " SELinux policy", " - cross-distro: FIPS bootstrap and dispatch via snap-fips-dispatch", " - desktop: fix common ID selection with multiple desktop plugs", " - FDE: allow user mode on core in secboot TPM handling", " - FDE: bump go-efilib dependency", " - FDE: bump secboot to rev cdcb64992e54 for FDE fixes", " - FDE: deprecate check-pin/passphrase API endpoints", " - LP: #2147606 FDE: give inactive state on classic", " - FDE: improve tracing for OP-TEE probing", " - FDE: move auto-repair logic to overlord/fdestate and provide state", " - FDE: update secboot for TPM/FDE bug fixes including Intel HAP and", " recovery key parsing", " - FDE: use any primary key matching digest when adding a keyslot", " - FDE: use ignore action for preinstall check in VM", " - interfaces: bluez | drop explicit deny send_destination in D-Bus", " configuration", " - interfaces: conditionally deny /proc/self/mountinfo to suppress Go", " 1.25+ denials", " - interfaces: custom-device | fix for-device validation panic on", " non-string value", " - interfaces: disallow auto-connect to parallel installs", " - interfaces: docker | make plug implicit on classic systems", " - interfaces: ignore errors in disconnect hooks during explicit snap", " disconnect", " - interfaces: mediatek-accel | add plug interface base declaration", " - interfaces: microceph-support | suppress noisy sudo denial audit", " logs", " - interfaces: podman | add new interface for podman socket access", " - interfaces: pulseaudio | fix security tag syntax inconsistency", " - interfaces: raw-usb | allow USB device enumeration on Fairphone 5", " with NexDock", " - interfaces: restore auto-connections on failed refresh undo", " - LP: #2148544 interfaces: bool-file | support deep SoC sysfs paths", " for LED brightness", " - LP: #2139213 packaging: make Ubuntu 16.04 packaging dep17", " compliant", " - packaging: add cross-distro build script and instructions", " - packaging: add openSUSE 16.0 spread support", " - packaging: Debian build improvements", " - packaging: default openSUSE to /var/lib/snapd/snap and sync from", " downstream", " - packaging: drop transitional packages only for Ubuntu 26.04", " (Resolute)", " - packaging: fix Launchpad FIPS build detection for snapd-fips job", " - packaging: refactor and clean up snapd.mk, standardize test-data", " directories", " - packaging: switch to golang-github-chai2010-gettext-go-dev", " - packaging: update bundled AppArmor 4.1.7 (snapd snap only)", " - prompting: escape paths in prompt constraints", " - prompting: improve API error handling and validation", " - prompting: improve error message when no handler service is", " present", " - prompting: re-enable the prompting notice backend", " - prompting: respond with full user-allowed permission set", " - prompting: validate permissions while unmarshalling", " - remote device management: implement dispatch-mgmt-messages task", " with sequencing support", " - LP: #2125344 snap: avoid empty channel forwarding message", " - LP: #2150683 snap: clarify snap install help text for --classic", " and --devmode", " - LP: #2152908 snap: print complex attributes in snap interface", " --attrs output", " - snap: add run-inhibit hint and inhibit info when a snap is", " disabled", " - snap: allow removing a snap and its base at the same time", " - snap: display detailed component information in snap info", " - snap: extend AlreadyInstalledError to multiple snaps and", " components", " - snap: extend set-quota command options description with accepted", " value formats", " - snap: implement snap delta command for computing snap deltas", " - snap: improve consistency for snap install when some snaps are", " already installed", " - snap: show hint in snap list that a snap has components", " - snap-confine: allow inheriting unix sockets from snaps", " - snap-confine: allow linking to libm in AppArmor profile", " - snap-confine: fix out-of-bounds read in mountinfo parser for", " partial escape sequences", " - snap-confine: harden bpffs mount with nosuid, nodev, noexec flags", " - snap-confine: remove experimental persistent per-user mount", " namespace feature", " - snap-confine: set FD_CLOEXEC on file descriptors returned by BPF", " helpers", " - snap-confine: support transparent_hugepage in AppArmor profile", " - snap-confine: use strchr after NUL-terminating in infofile parser", " - snap-update-ns: switch to a multi-pass process for constructing", " and updating mount namespaces", " - RemoveMountUnitFile now unmounts even if mount unit file is", " missing", " - Add explicit mount phase during single-reboot refresh to fix undo", " of kernel refreshes", " - Add security audit logging subsystem", " - Add base prioritized AppArmmor snippets for strictly confined or", " jailed snaps", " - Allow openshell snap to use experimental daemon-scope: user", " - Allow configuring mount unit options based on filesystem type", " - Allow equals signs in uevent values in netlink parser", " - Also bind-mount directories modified by kmod backend during", " preseed", " - Clean up potentially corrupted files during snap download undo", " - Complete the bootloader environment implementation", " - Copy integrity data files during snap install", " - Create hook for seed refresh mode", " - Create removal tasks for old seed-refresh seeds", " - Dispatch systemctl commands asynchronously when calling Stop()", " - Ensure /tmp/.X11-unix created inside mount namespace has correct", " permissions", " - Ensure exclusive changes conflict with refresh/revert", " - Ensure existing snap confinement flags are not dropped when", " installing or removing components", " - Export ubuntu-boot-state filename constant from bootloader package", " - Fix duplicate removal of apps under $SNAP_MOUNT_DIR/bin", " - Fix integration between prerequisites task and seed-refresh mode", " - Fix split-refresh overwriting provided lane", " - Fix use of umask in GetListener for socket activation", " - Ignore net.ErrClosed during daemon shutdown", " - Implement ResolveValidationSetsEnforcementError in terms of one", " call", " - Improve snapctl install consistency when components are already", " installed", " - Inject seed creation tasks into snap refresh flow", " - Introduce system options for custom certificates on Ubuntu Core", " - Keep idle services with activation units stopped on reload", " - List snap components in snap-debug-info via debug-tools", " - Look at gadget.yaml instead of marker file to determine ubootpart", " usage", " - LP: #1966067 Skip redundant xdg-settings confirmation prompt when", " setting is already correct", " - LP: #2110368 Fix component installation for private snaps via", " snapctl", " - LP: #2110368 Fix download of private snap components by setting", " UserID", " - LP: #2144666 Fix mount namespace updates with synthetic bind", " mounts on same target paths", " - LP: #2146337 Improve handling of failed downloads and retain", " partial files for resume", " - LP: #2147207 Fix snap enable/disable cycle forgetting components", " - Make run-inhibit hint for kill-snap-apps task based on kill reason", " - Merge content-provider prerequisite updates into seed-refresh", " - Move SortServices into Backend.StartServices", " - Move state to client change conversion to ctlcmd package", " - Omit misleading \"try to refresh snapd\" suggestion for ISA-related", " errors", " - Only create link-component tasks when needed during refresh to", " existing revision", " - Reconfigure piboot bootloader on gadget refreshes to preserve", " os_prefix", " - Reduce the number of AppArmor profile regenerations during snap", " operations", " - Refactor seed-refresh ownership to devicestate", " - Regenerate certificate database on remodels", " - Remove obsolete FIXME comment in VersionCompare", " - Remove unused GenerateDmVerityData helper from snap/integrity", " - Rename and document error type for ISA assumes flags", " - Restart snapd from daemon.Stop to improve restart reliability", " - Restart stopped services on error in stopSnapServices for", " transactionality", " - Simplify certificate-db updates on model-base refresh/installs", " - Support racing Loop and Stop correctly in overlord", " - Support sending file descriptors to systemd via sd_notify", " - Unroll CPU-heavy recursive function in snap state handlers", " - Update seccomp syscalls list for kernel 7.1.0", " - Use change ID to prevent nested seed-refresh spawned by", " prerequisites", " - Validate content interface plug target directories exist for", " core26+ snaps", " - Validate layout paths exist in snap tree for snaps using bare or", " core26+", "" ], "package": "snapd", "version": "2.76", "urgency": "medium", "distributions": "xenial", "launchpad_bugs_fixed": [ 2154498, 2147606, 2148544, 2139213, 2125344, 2150683, 2152908, 1966067, 2110368, 2110368, 2144666, 2146337, 2147207 ], "author": "Ernest Lotter ", "date": "Thu, 28 May 2026 20:00:16 +0200" }, { "cves": [], "log": [ "", " * New upstream release, LP: #2143882", " - Interfaces: network-setup-*| allow running python binaries from", " the base on UC26+", " - Cross-distro: modify SELinux policy to allow mounting on", " /var/snap//", " - Fix potential task deadlock by considering all tasks in a lane", " that might be waiting for a reboot when processing delayed", " security backend effects", "" ], "package": "snapd", "version": "2.75.2", "urgency": "medium", "distributions": "xenial", "launchpad_bugs_fixed": [ 2143882 ], "author": "Katie May ", "date": "Mon, 30 Mar 2026 17:06:36 +0200" } ], "notes": null, "is_version_downgrade": false }, { "name": "systemd", "from_version": { "source_package_name": "systemd", "source_package_version": "255.4-1ubuntu8.17", "version": "255.4-1ubuntu8.17" }, "to_version": { "source_package_name": "systemd", "source_package_version": "255.4-1ubuntu8.18", "version": "255.4-1ubuntu8.18" }, "cves": [], "launchpad_bugs_fixed": [ 2170538 ], "changes": [ { "cves": [], "log": [ "", " * d/p/lp2170538-resolved-pick-up-new-DNSSEC-KSK-from-2024.patch: add", " the root zone KSK-2024 (key tag 38696) to the built-in DNSSEC trust", " anchor. Since 2026-10-11 the root DNSKEY RRset is signed only by", " this key, so with DNSSEC enabled and no local trust anchor file", " every lookup failed with \"missing-key\" (LP: #2170538)", "" ], "package": "systemd", "version": "255.4-1ubuntu8.18", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [ 2170538 ], "author": "CyberNative AI LLC ", "date": "Mon, 12 Oct 2026 07:36:16 +0000" } ], "notes": null, "is_version_downgrade": false }, { "name": "systemd-dev", "from_version": { "source_package_name": "systemd", "source_package_version": "255.4-1ubuntu8.17", "version": "255.4-1ubuntu8.17" }, "to_version": { "source_package_name": "systemd", "source_package_version": "255.4-1ubuntu8.18", "version": "255.4-1ubuntu8.18" }, "cves": [], "launchpad_bugs_fixed": [ 2170538 ], "changes": [ { "cves": [], "log": [ "", " * d/p/lp2170538-resolved-pick-up-new-DNSSEC-KSK-from-2024.patch: add", " the root zone KSK-2024 (key tag 38696) to the built-in DNSSEC trust", " anchor. Since 2026-10-11 the root DNSKEY RRset is signed only by", " this key, so with DNSSEC enabled and no local trust anchor file", " every lookup failed with \"missing-key\" (LP: #2170538)", "" ], "package": "systemd", "version": "255.4-1ubuntu8.18", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [ 2170538 ], "author": "CyberNative AI LLC ", "date": "Mon, 12 Oct 2026 07:36:16 +0000" } ], "notes": null, "is_version_downgrade": false }, { "name": "systemd-resolved", "from_version": { "source_package_name": "systemd", "source_package_version": "255.4-1ubuntu8.17", "version": "255.4-1ubuntu8.17" }, "to_version": { "source_package_name": "systemd", "source_package_version": "255.4-1ubuntu8.18", "version": "255.4-1ubuntu8.18" }, "cves": [], "launchpad_bugs_fixed": [ 2170538 ], "changes": [ { "cves": [], "log": [ "", " * d/p/lp2170538-resolved-pick-up-new-DNSSEC-KSK-from-2024.patch: add", " the root zone KSK-2024 (key tag 38696) to the built-in DNSSEC trust", " anchor. Since 2026-10-11 the root DNSKEY RRset is signed only by", " this key, so with DNSSEC enabled and no local trust anchor file", " every lookup failed with \"missing-key\" (LP: #2170538)", "" ], "package": "systemd", "version": "255.4-1ubuntu8.18", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [ 2170538 ], "author": "CyberNative AI LLC ", "date": "Mon, 12 Oct 2026 07:36:16 +0000" } ], "notes": null, "is_version_downgrade": false }, { "name": "systemd-sysv", "from_version": { "source_package_name": "systemd", "source_package_version": "255.4-1ubuntu8.17", "version": "255.4-1ubuntu8.17" }, "to_version": { "source_package_name": "systemd", "source_package_version": "255.4-1ubuntu8.18", "version": "255.4-1ubuntu8.18" }, "cves": [], "launchpad_bugs_fixed": [ 2170538 ], "changes": [ { "cves": [], "log": [ "", " * d/p/lp2170538-resolved-pick-up-new-DNSSEC-KSK-from-2024.patch: add", " the root zone KSK-2024 (key tag 38696) to the built-in DNSSEC trust", " anchor. Since 2026-10-11 the root DNSKEY RRset is signed only by", " this key, so with DNSSEC enabled and no local trust anchor file", " every lookup failed with \"missing-key\" (LP: #2170538)", "" ], "package": "systemd", "version": "255.4-1ubuntu8.18", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [ 2170538 ], "author": "CyberNative AI LLC ", "date": "Mon, 12 Oct 2026 07:36:16 +0000" } ], "notes": null, "is_version_downgrade": false }, { "name": "systemd-timesyncd", "from_version": { "source_package_name": "systemd", "source_package_version": "255.4-1ubuntu8.17", "version": "255.4-1ubuntu8.17" }, "to_version": { "source_package_name": "systemd", "source_package_version": "255.4-1ubuntu8.18", "version": "255.4-1ubuntu8.18" }, "cves": [], "launchpad_bugs_fixed": [ 2170538 ], "changes": [ { "cves": [], "log": [ "", " * d/p/lp2170538-resolved-pick-up-new-DNSSEC-KSK-from-2024.patch: add", " the root zone KSK-2024 (key tag 38696) to the built-in DNSSEC trust", " anchor. Since 2026-10-11 the root DNSKEY RRset is signed only by", " this key, so with DNSSEC enabled and no local trust anchor file", " every lookup failed with \"missing-key\" (LP: #2170538)", "" ], "package": "systemd", "version": "255.4-1ubuntu8.18", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [ 2170538 ], "author": "CyberNative AI LLC ", "date": "Mon, 12 Oct 2026 07:36:16 +0000" } ], "notes": null, "is_version_downgrade": false }, { "name": "tzdata", "from_version": { "source_package_name": "tzdata", "source_package_version": "2026c-0ubuntu0.24.04.1", "version": "2026c-0ubuntu0.24.04.1" }, "to_version": { "source_package_name": "tzdata", "source_package_version": "2026e-0ubuntu0.24.04.1", "version": "2026e-0ubuntu0.24.04.1" }, "cves": [], "launchpad_bugs_fixed": [ 2169125 ], "changes": [ { "cves": [], "log": [ "", " * New upstream release (LP: #2169125):", " - Canada’s Northwest Territories moved to permanent -06 on 2026-08-21 and", " will not fall back from -06 to -07 on 2026-11-01", " - Manitoba moves to permanent -05 on 2026-10-31 and will not fall back", " from -05 to -06 on 2026-11-01", " * Add autopkgtest test cases for 2026d and 2026e releases", " * Revert POSIX conformance of old SysV names EST5EDT, CST6CDT, MST7MDT and", " PST8PDT", " * Update the ICU timezone data to 2026e", " * Add autopkgtest test case for ICU timezone data 2026d and 2026e", "" ], "package": "tzdata", "version": "2026e-0ubuntu0.24.04.1", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2169125 ], "author": "Benjamin Drung ", "date": "Mon, 05 Oct 2026 11:20:05 +0200" } ], "notes": null, "is_version_downgrade": false }, { "name": "udev", "from_version": { "source_package_name": "systemd", "source_package_version": "255.4-1ubuntu8.17", "version": "255.4-1ubuntu8.17" }, "to_version": { "source_package_name": "systemd", "source_package_version": "255.4-1ubuntu8.18", "version": "255.4-1ubuntu8.18" }, "cves": [], "launchpad_bugs_fixed": [ 2170538 ], "changes": [ { "cves": [], "log": [ "", " * d/p/lp2170538-resolved-pick-up-new-DNSSEC-KSK-from-2024.patch: add", " the root zone KSK-2024 (key tag 38696) to the built-in DNSSEC trust", " anchor. Since 2026-10-11 the root DNSKEY RRset is signed only by", " this key, so with DNSSEC enabled and no local trust anchor file", " every lookup failed with \"missing-key\" (LP: #2170538)", "" ], "package": "systemd", "version": "255.4-1ubuntu8.18", "urgency": "medium", "distributions": "noble-security", "launchpad_bugs_fixed": [ 2170538 ], "author": "CyberNative AI LLC ", "date": "Mon, 12 Oct 2026 07:36:16 +0000" } ], "notes": null, "is_version_downgrade": false } ], "snap": [] }, "added": { "deb": [ { "name": "linux-image-6.8.0-147-generic", "from_version": { "source_package_name": "linux-signed", "source_package_version": "6.8.0-146.146", "version": null }, "to_version": { "source_package_name": "linux-signed", "source_package_version": "6.8.0-147.147", "version": "6.8.0-147.147" }, "cves": [], "launchpad_bugs_fixed": [ 1786013 ], "changes": [ { "cves": [], "log": [ "", " * Main version: 6.8.0-147.147", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian/tracking-bug -- resync from main package", "" ], "package": "linux-signed", "version": "6.8.0-147.147", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 1786013 ], "author": "Stefan Bader ", "date": "Thu, 24 Sep 2026 12:28:05 +0200" } ], "notes": "linux-image-6.8.0-147-generic version '6.8.0-147.147' (source package linux-signed version '6.8.0-147.147') was added. linux-image-6.8.0-147-generic version '6.8.0-147.147' has the same source package name, linux-signed, as removed package linux-image-6.8.0-146-generic. As such we can use the source package version of the removed package, '6.8.0-146.146', as the starting point in our changelog diff. Kernel packages are an example of where the binary package name changes for the same source package. Using the removed package source package version as our starting point means we can still get meaningful changelog diffs even for what appears to be a new package.", "is_version_downgrade": false }, { "name": "linux-modules-6.8.0-147-generic", "from_version": { "source_package_name": "linux", "source_package_version": "6.8.0-146.146", "version": null }, "to_version": { "source_package_name": "linux", "source_package_version": "6.8.0-147.147", "version": "6.8.0-147.147" }, "cves": [ { "cve": "CVE-2026-68371", "url": "https://ubuntu.com/security/CVE-2026-68371", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: musb: omap2430: Do not put borrowed of_node in probe omap2430_probe() stores pdev->dev.of_node in a local np variable. This is a borrowed pointer and the probe function does not take a reference to it. The success and error paths nevertheless call of_node_put(np). This drops a reference that is owned by the platform device, and can leave pdev->dev.of_node with an unbalanced reference count. Do not put the borrowed platform device node from omap2430_probe(). References taken for the child MUSB device are handled by the device core, and the ctrl-module phandle reference is still released separately.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-72130", "url": "https://ubuntu.com/security/CVE-2026-72130", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-auth: reject short AUTH_RECEIVE buffers nvmet_execute_auth_receive() trusts the AUTH_RECEIVE allocation length after checking only that it is nonzero and matches the transfer length. In the SUCCESS1 and FAILURE1/default states, that lets a remote NVMe-oF initiator reach the fixed-size DH-HMAC-CHAP response builders with a kmalloc() buffer shorter than the response, so nvmet_auth_success1() and nvmet_auth_failure1() write past the allocation; both only WARN_ON the short length and then format the message anyway. Impact: A remote NVMe-oF initiator with access to an auth-enabled target can trigger a 16-byte heap out-of-bounds write via a one-byte AUTH_RECEIVE allocation length. Compute the minimum response length for the current DH-HMAC-CHAP step in nvmet_auth_receive_data_len() and report a zero data length when the host-supplied allocation length is shorter, so the existing zero-length check in nvmet_execute_auth_receive() rejects the command before any builder runs. The SUCCESS1 minimum is sizeof(struct nvmf_auth_dhchap_success1_data) plus the HMAC hash length, because the response hash is written into the rval[] flexible-array tail, so the minimum is state dependent rather than a flat sizeof. CHALLENGE keeps its existing variable-length guard in nvmet_auth_challenge(). This is reachable only when in-band DH-HMAC-CHAP authentication is configured on the target.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72168", "url": "https://ubuntu.com/security/CVE-2026-72168", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: maps: vmu-flash: fix fault in unaligned fixup Use kzalloc_obj() / kzalloc_objs() to allocate the memcard structs, instead of kmalloc_obj() / kmalloc_objs() to prevent access to uninitialized data. Fixes runtime error: Fault in unaligned fixup: 0000 [#1] at mtd_get_fact_prot_info.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72213", "url": "https://ubuntu.com/security/CVE-2026-72213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: fix hugetlb cgroup rsvd charge/uncharge mismatch In alloc_hugetlb_folio(), a single h_cg pointer is used for both the rsvd and non-rsvd hugetlb cgroup charges. When map_chg is set, hugetlb_cgroup_charge_cgroup_rsvd() stores the charged cgroup in h_cg, but the immediately following hugetlb_cgroup_charge_cgroup() overwrites h_cg with the non-rsvd cgroup pointer. As a result, hugetlb_cgroup_commit_charge_rsvd() stores the wrong (non-rsvd) cgroup pointer into the folio's rsvd slot. When the folio is later freed, free_huge_folio() unconditionally calls both hugetlb_cgroup_uncharge_folio() and hugetlb_cgroup_uncharge_folio_rsvd(). The rsvd uncharge reads back the wrong cgroup from the folio and decrements a counter that was never charged for that cgroup, causing a page_counter underflow: page_counter underflow: -512 nr_pages=512 WARNING: mm/page_counter.c:61 at page_counter_cancel Fix this by introducing a separate h_cg_rsvd pointer exclusively for the rsvd charge path, keeping the rsvd and non-rsvd charges fully independent through their charge, commit, and error uncharge paths.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72244", "url": "https://ubuntu.com/security/CVE-2026-72244", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpu/buddy: bail out of try_harder when alignment cannot be honoured The try_harder contiguous fallback could return a range whose start offset did not match the caller's min_block_size. When a candidate's start is misaligned, realign it: free the misaligned run and reallocate exactly @size at the next lower min_block_size boundary. This keeps the returned size unchanged with no surplus to trim, and rejects the request only when no aligned candidate fits. v2: align misaligned candidates down to min_block_size instead of bailing out, for both the RHS and LHS paths (Matthew).", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-68129", "url": "https://ubuntu.com/security/CVE-2026-68129", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gve: fix Rx queue stall on alloc failure When the system is under extreme memory pressure, page allocations can fail during the Rx buffer refill loop. If the number of buffers posted to hardware falls below a critical low threshold and the refill loop exits due to allocation failures, the queue can stall: 1. The device drops incoming packets because there are no descriptors. 2. Since no packets are processed, no Rx completions are generated. 3. Because no completions occur, NAPI is never scheduled, preventing the refill loop from running again even after memory is freed. This results in a permanent queue stall. Resolve this by introducing a starvation recovery timer for each Rx queue. If the number of buffers posted to hardware falls below a critical low threshold, start a timer to periodically reschedule NAPI. Once NAPI runs and successfully refills the queue above the threshold, the timer is not rescheduled. The threshold is set to 32 because a single maximum-sized Receive Segment Coalescing (RSC) packet can consume up to 19 descriptors in the Rx path. Lower thresholds (such as 8 or 16) would be insufficient to process a complete maximum-sized RSC packet, risking packet drops or unexpected hardware behavior under memory pressure. Setting the threshold to 32 guarantees a safe margin to handle at least one full RSC packet.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-53078", "url": "https://ubuntu.com/security/CVE-2026-53078", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix same-register dst/src OOB read and pointer leak in sock_ops When a BPF sock_ops program accesses ctx fields with dst_reg == src_reg, the SOCK_OPS_GET_SK() and SOCK_OPS_GET_FIELD() macros fail to zero the destination register in the !fullsock / !locked_tcp_sock path. Both macros borrow a temporary register to check is_fullsock / is_locked_tcp_sock when dst_reg == src_reg, because dst_reg holds the ctx pointer. When the check is false (e.g., TCP_NEW_SYN_RECV state with a request_sock), dst_reg should be zeroed but is not, leaving the stale ctx pointer: - SOCK_OPS_GET_SK: dst_reg retains the ctx pointer, passes NULL checks as PTR_TO_SOCKET_OR_NULL, and can be used as a bogus socket pointer, leading to stack-out-of-bounds access in helpers like bpf_skc_to_tcp6_sock(). - SOCK_OPS_GET_FIELD: dst_reg retains the ctx pointer which the verifier believes is a SCALAR_VALUE, leaking a kernel pointer. Fix both macros by: - Changing JMP_A(1) to JMP_A(2) in the fullsock path to skip the added instruction. - Adding BPF_MOV64_IMM(si->dst_reg, 0) after the temp register restore in the !fullsock path, placed after the restore because dst_reg == src_reg means we need src_reg intact to read ctx->temp.", "cve_priority": "low", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-68119", "url": "https://ubuntu.com/security/CVE-2026-68119", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: initialize standalone TCP-AO response padding tcp_v4_send_ack() and tcp_v6_send_response() construct standalone TCP responses with TCP-AO options. The option length carries the actual MAC length, but the TCP header length includes the option rounded up to a four-byte boundary. tcp_ao_hash_hdr() writes the MAC only. Thus, when the MAC length is not four-byte aligned, the one to three bytes after the MAC are left uninitialized and may be transmitted. For the normal TCP-AO hashing mode, those bytes also have to be initialized before computing the MAC. Initialize only the alignment padding in the TCP-AO branches, before hashing the header. Use TCPOPT_NOP, as in the normal TCP-AO output path. This avoids adding work to non-AO TCP responses while preserving a valid authenticated header.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68136", "url": "https://ubuntu.com/security/CVE-2026-68136", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: gro: fix double aggregation of flush-marked skbs Commit 0ab03f353d36 (\"net-gro: Fix GRO flush when receiving a GSO packet.\") added a flush check to skb_gro_receive(), but skb_gro_receive_list() lacks the same validation. As a result, packets marked with NAPI_GRO_CB(skb)->flush may still be re-aggregated. This allows already-GRO'd packets with existing frag_list to be re-aggregated into a new GRO session, corrupting the frag_list chain structure. When skb_segment() attempts to unpack these malformed packets, it encounters invalid state and triggers a kernel panic. Scenario (Tethering/Device forwarding): 1. Driver: Generated aggregated packet P1 via LRO with frag_list 2. Dev A: Receives aggregated fraglist packet and flush flag set 3. Dev A: Re-enters GRO, skb_gro_receive_list() is called 4. Missing flush check allows re-aggregation despite flush flag 5. Frag_list chain becomes corrupted (loops or dangling refs) 6. Dev B: TX path calls skb_segment(), crashes on corrupted frag_list Root cause in skb_segment(): The check at line ~4891: if (hsize <= 0 && i >= nfrags && skb_headlen(list_skb) && (skb_headlen(list_skb) == len || sg)) { When frag_list is corrupted by double aggregation, when list_skb is a NULL pointer from skb->next, skb_headlen(list_skb) dereference NULL/corrupted pointers occurs. Call Trace: skb_headlen(NULL skb) skb_segment tcp_gso_segment tcp4_gso_segment inet_gso_segment skb_mac_gso_segment __skb_gso_segment skb_gso_segment validate_xmit_skb validate_xmit_skb_list sch_direct_xmit qdisc_restart __qdisc_run qdisc_run net_tx_action Fix: Add NAPI_GRO_CB(skb)->flush validation to the early-return check in skb_gro_receive_list(), matching the defensive programming pattern of skb_gro_receive().", "cve_priority": "high", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68139", "url": "https://ubuntu.com/security/CVE-2026-68139", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Use sender devcom for MPV master-up After PCIe DPC recovery, mlx5 reloads the affected functions and replays multiport affiliation events. In the reported failure, the first relevant device error was: pcieport 0000:10:01.1: DPC: containment event pcieport 0000:10:01.1: PCIe Bus Error: severity=Uncorrected (Fatal) pcieport 0000:10:01.1: [ 5] SDES (First) mlx5 recovered the PCI functions and resumed 0000:11:00.1. During that resume, RDMA multiport binding replayed MLX5_DRIVER_EVENT_AFFILIATION_DONE and mlx5e sent MPV_DEVCOM_MASTER_UP. The host then panicked with: BUG: kernel NULL pointer dereference, address: 0000000000000010 RIP: mlx5_devcom_comp_set_ready+0x5/0x40 [mlx5_core] RDI: 0000000000000000 Call trace included: mlx5_devcom_comp_set_ready mlx5e_devcom_event_mpv mlx5_devcom_send_event mlx5_ib_bind_slave_port mlx5r_mp_probe mlx5_pci_resume MPV devcom registration publishes mlx5e private data to the component peer list before mlx5e_devcom_init_mpv() stores the returned component device in priv->devcom. A concurrent master-up event can therefore reach a peer whose private data is visible but whose priv->devcom backpointer is still NULL. MPV_DEVCOM_MASTER_UP already carries the sender/master mlx5e private data as event_data. The ready bit is stored on the shared devcom component, not on an individual peer. Use the sender devcom when marking the MPV component ready. This preserves the readiness transition while avoiding a NULL dereference of the peer devcom pointer during affiliation replay after PCI error recovery.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68145", "url": "https://ubuntu.com/security/CVE-2026-68145", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iomap: fix out-of-bounds bitmap_set() with zero-length range ifs_set_range_dirty() and ifs_set_range_uptodate() compute last_blk as (off + len - 1) >> i_blkbits. When off is 0 and len is 0, the unsigned subtraction underflows to SIZE_MAX, producing a huge last_blk and nr_blks value that causes bitmap_set() to write far beyond the ifs->state allocation. Regarding ifs_set_range_uptodate(), it is temporarily safe because len cannot be passed in as 0. However, for ifs_set_range_dirty() this is reachable from __iomap_write_end(): when copy_folio_from_iter_atomic() returns 0 (e.g. user buffer fault) and the folio is already uptodate, the guard at the top of __iomap_write_end() does not trigger because !folio_test_uptodate() is false, and iomap_set_range_dirty() is called with copied == 0. Add a !len guard to both functions before the computation, so that a zero-length range is a no-op.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68161", "url": "https://ubuntu.com/security/CVE-2026-68161", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: close UDP tunnel sockets during netns teardown proc_sctp_do_udp_port() starts per-net SCTP UDP tunneling sockets when net.sctp.udp_port is set, and stops/restarts them when the sysctl value changes. The netns exit path does not stop these sockets, so a namespace can be torn down while its SCTP UDP tunnel sockets are still installed. Close the UDP tunnel sockets from sctp_ctrlsock_exit() after unregistering the per-net sysctl table. This prevents new sysctl writes from racing in while the sockets are being released, and closes the sockets before the control socket is destroyed.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68162", "url": "https://ubuntu.com/security/CVE-2026-68162", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: avoid auth_enable sysctl UAF during netns teardown proc_sctp_do_auth() updates the SCTP control socket after changing net.sctp.auth_enable. The handler gets the per-net SCTP state from ctl->data, so an already opened sysctl file can still target a network namespace while that namespace is being torn down. SCTP previously registered its per-net sysctls from sctp_defaults_init(), while the control socket is created later from sctp_ctrlsock_init(). This exposed a window during initialization where auth_enable was writable before net->sctp.ctl_sock existed, and a teardown window where auth_enable stayed writable after inet_ctl_sock_destroy() had released the control socket. Move the per-net SCTP sysctl registration into sctp_ctrlsock_init() after sctp_ctl_sock_init() succeeds, and unregister the sysctl table before destroying the control socket in sctp_ctrlsock_exit(). If sysctl registration fails after the control socket was created, destroy the control socket in the same init path. Make sctp_sysctl_net_unregister() tolerate a missing header and clear the saved pointer so init-error and exit paths can safely share the unregister helper.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68178", "url": "https://ubuntu.com/security/CVE-2026-68178", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: nsm: pin the module while the device is open misc_open() installs a misc driver's file operations with fops_get(), which pins file_operations::owner before replacing the file's f_op. The NSM misc device leaves nsm_dev_fops.owner unset, so opening /dev/nsm does not take a module reference on the nsm driver. If the driver is built as a module, an open file descriptor can therefore survive rmmod of the module that provides its ioctl callbacks. A later ioctl through that descriptor can call into unloaded module text. Set nsm_dev_fops.owner to THIS_MODULE so the misc core holds the module while any /dev/nsm file descriptor is open, matching the lifetime expectation for the installed file operations.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68179", "url": "https://ubuntu.com/security/CVE-2026-68179", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: nsm: only unlock nsm_dev on post-lock error paths nsm_dev_ioctl() jumps to the common out label even when the initial copy_from_user() fails before nsm->lock has been taken. The error path then blindly unlocks a mutex that was never acquired. This issue was found by our static analysis tool and then manually reviewed against the current tree. The grounded PoC kept the miscdevice ioctl entry and the pre-lock copy_from_user(&raw, argp, _IOC_SIZE(cmd)) failure path by issuing NSM_IOCTL_RAW with an invalid user pointer. That failure reaches the shared out label before mutex_lock(&nsm->lock). Lockdep reported: WARNING: bad unlock balance detected! exploit/193 is trying to release lock (&global_nsm.lock) at: nsm_dev_ioctl+0x5f/0xcf [vuln_msv] but there are no more locks to release! no locks held by exploit/193. Return immediately on the pre-lock copy_from_user() failure and keep the common unlock label for the post-lock paths only.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68183", "url": "https://ubuntu.com/security/CVE-2026-68183", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: stratix10-svc: fix memory leaks and list corruption bugs Fix a memory leak when gen_pool_alloc() fails by freeing pmem on the error path. Switch pmem allocation from devm_kzalloc() to kzalloc() with explicit kfree() in the free path to match its list-managed lifetime. Remove the erroneous list_del(&svc_data_mem) which corrupted the list head on failed lookups.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68193", "url": "https://ubuntu.com/security/CVE-2026-68193", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7925: drop TXRX_NOTIFY on non-mmio buses PKT_TYPE_TXRX_NOTIFY is an mmio-only event, but mt7925_rx_check() and mt7925_queue_rx_skb() dispatch it to mt7925_mac_tx_free() on every bus. mt7925_mac_tx_free() cleans the DMA tx queues with mt76_queue_tx_cleanup(), which calls queue_ops->tx_cleanup(). Only the mmio queue ops implement that callback; on USB it is NULL, so a TXRX_NOTIFY there calls a NULL pointer in the RX worker: BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:0x0 Call Trace: mt7925_mac_tx_free+0x58/0x350 [mt7925_common] mt7925_rx_check+0xe2/0x130 [mt7925_common] mt76u_rx_worker+0x1b9/0x620 [mt76_usb] Drop the event on non-mmio buses via mt76_is_mmio(), as in commit 5683e1488aa9 (\"wifi: mt76: connac: do not check WED status for non-mmio devices\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68203", "url": "https://ubuntu.com/security/CVE-2026-68203", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: vivid: fix cleanup bugs in vivid_init() When platform_device_register() fails in vivid_init(), the embedded struct device in vivid_pdev has already been initialized by device_initialize(), but the failure path jumps to free_output_strings without dropping the device reference for the current platform device: vivid_init() -> platform_device_register(&vivid_pdev) -> device_initialize(&vivid_pdev.dev) -> setup_pdev_dma_masks(&vivid_pdev) -> platform_device_add(&vivid_pdev) This leads to a reference leak when platform_device_register() fails. Fix this by calling platform_device_put() before jumping to the common cleanup path. Also, the unreg_driver label incorrectly calls platform_driver_register() instead of platform_driver_unregister(), which breaks cleanup when workqueue creation fails after successful driver registration. Fix that as well. The reference leak was identified by a static analysis tool I developed and confirmed by manual review. The incorrect cleanup call was found during code inspection.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68205", "url": "https://ubuntu.com/security/CVE-2026-68205", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: v4l2-fwnode: Fix subdev owner overwritten in v4l2_async_register_subdev_sensor() The v4l2 helper v4l2_async_register_subdev_sensor() calls v4l2_async_register_subdev(), which is a macro that expands to __v4l2_async_register_subdev(sd,THIS_MODULE). Since the macro is expanded inside v4l2-fwnode.c, THIS_MODULE resolves to the v4l2-fwnode module rather than the sensor driver module that originally set sd->owner. When v4l2-fwnode is built-in, THIS_MODULE evaluates to NULL, which then overwrites the sensor driver's owner with NULL. This causes the problem that the sensor module's reference count is never incremented during async registration, so the module can be removed while the subdevice is still in use by a notifier (e.g., a CSI-2 receiver bridge driver). Fix this by renaming v4l2_async_register_subdev_sensor() to __v4l2_async_register_subdev_sensor() with an added explicit module argument and introducing a wrapper macro: #define v4l2_async_register_subdev_sensor(sd) \\ __v4l2_async_register_subdev_sensor(sd, THIS_MODULE) This ensures the sensor driver module is properly referenced even when the sensor driver does not init the owner field before calling v4l2_async_register_subdev_sensor() and prevents premature module removal.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68221", "url": "https://ubuntu.com/security/CVE-2026-68221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: nuvoton: npcm-video: fix memory leaks in probe and remove npcm_video_probe() allocates the npcm_video structure with kzalloc_obj() but never frees it on any probe error path or in npcm_video_remove(), leaking the allocation on every failed probe and every normal unbind. Additionally, when npcm_video_setup_video() fails, the reserved memory association established by of_reserved_mem_device_init() in npcm_video_init() is not released, leaking the rmem_assigned_device entry on the global list. Fix both by adding kfree(video) to all probe error paths and to npcm_video_remove(), and adding the missing of_reserved_mem_device_release() call when npcm_video_setup_video() fails.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68225", "url": "https://ubuntu.com/security/CVE-2026-68225", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: i2c: alvium: fix critical pointer access in alvium_ctrl_init The current implementation of alvium_ctrl_init creates several controls in function alvium_ctrl_init and uses the returned pointer without check. That can cause write access over NULL-pointer for several controls. The reworked code checks the pointers before adding flags.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68228", "url": "https://ubuntu.com/security/CVE-2026-68228", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: chips-media: wave5: Move src_buf Removal to finish_encode During encoder processing, there is a case where the IRQ response could return the buffer back to userspace via v4l2_m2m_buf_done call. In this time, userspace could queue up this same buffer before start_encode removes the index from the ready queue. This would then lead to a case where the buffer in the ready queue could be a self loop due to the WRITE_ONCE(prev->next, new) call in __list_add. When __list_del is finally called, the loop is already made so nothing points back to ready queue list head and pointers are poisoned. A buffer should not be marked as DONE before the buffer is removed from m2m ready queue. Move removal entirely to finish_encode.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68235", "url": "https://ubuntu.com/security/CVE-2026-68235", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: dce100: skip non-DP stream encoders for DP MST On DCE8-class ASICs (e.g. Bonaire), the resource pool contains digital DIG stream encoders plus one analog DAC encoder. When assigning a stream encoder for a second DisplayPort MST stream, if the preferred digital encoder is already acquired, dce100_find_first_free_match_stream_enc_for_link() falls back to the first free pool entry. That entry may be the analog encoder, whose funcs table lacks DP hooks such as dp_set_stream_attribute. The subsequent atomic commit then dereferences NULL function pointers in link_set_dpms_on() and crashes. Skip encoders without dp_set_stream_attribute when the stream uses a DP signal (including MST). Use dc_is_dp_signal(stream->signal) for the MST fallback path instead of checking only the link connector signal. Tested on: - GPU: AMD Radeon R7 260X (Bonaire / DCE8) - Board: Supermicro C9X299-PG300 - Setup: DP MST daisy chain, hotplug second monitor or have it connected on boot - Kernel: 7.1.3 (issue observed since 6.19) - Result: kernel oops without patch; dual monitors stable with patch (cherry picked from commit 28ec64943e3ee4d9b8d30cea61e380f1429953a8)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68247", "url": "https://ubuntu.com/security/CVE-2026-68247", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/bios: range check LFP Data Block panel_type2 While the panel_type from LFP Data Block is range checked, panel_type2 is not. Add a few helpers for range checking, and use them to not only check panel_type2, but also improve clarity and correctness in the panel type selection. Discovered using AI-assisted static analysis confirmed by Intel Product Security. v2: - Fix commit message typo (MichaÅ‚) - Add is_panel_type_pnp() (Ville) (cherry picked from commit c9ebe5d2f25729d6cfbbb1235d640bf67f9275df)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68260", "url": "https://ubuntu.com/security/CVE-2026-68260", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: acquire vm_ctx->lock before mapping memory to GPU VM The drm gpuvm code doesn't protect find operation against map operation, and the driver needs to ensure a map operation shouldn't happen when a find operation is in progress. In some cases a find operation will be in progress when doing map/unmap operations, and the find operation will do a NULL pointer dereference. An example of the stack trace of such NULL dereference is shown below: ``` Unable to handle kernel access to user memory without uaccess routines at virtual address 0000000000000010 [] drm_gpuva_find+0x28/0x6c [drm_gpuvm] [] pvr_vm_unmap+0x34/0x68 [powervr] [] pvr_ioctl_vm_unmap+0x2e/0x50 [powervr] [] drm_ioctl_kernel+0x8e/0xdc [] drm_ioctl+0x1be/0x3e0 [] __riscv_sys_ioctl+0xba/0xc4 [] do_trap_ecall_u+0x23e/0x3f4 [] handle_exception+0x168/0x174 ``` As all occurences of drm_gpuva_find*() are already guarded by vm_ctx->lock, make pvr_vm_map() to acquire this lock to prevent disturbing any find operation. This fixes the NULL deference problem in drm_gpuva_find*().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68261", "url": "https://ubuntu.com/security/CVE-2026-68261", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: fix error checking of pvr_vm_context_lookup() Since pvr_vm_context_lookup() returns either NULL or a pointer, then stop using IS_ERR() for checking the return value. Using IS_ERR() leads to the kernel oops reported below. It can be reproduced by passing an invalid VM context handle from userspace to the DRM_IOCTL_PVR_CREATE_CONTEXT ioctl. [ 92.733119] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000148 [ 92.742042] Mem abort info: [ 92.744890] ESR = 0x0000000096000004 [ 92.748686] EC = 0x25: DABT (current EL), IL = 32 bits [ 92.754020] SET = 0, FnV = 0 [ 92.757154] EA = 0, S1PTW = 0 [ 92.760337] FSC = 0x04: level 0 translation fault [ 92.765243] Data abort info: [ 92.768129] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 92.773626] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 92.778763] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 92.784098] user pgtable: 4k pages, 48-bit VAs, pgdp=000000088ed23000 [ 92.790550] [0000000000000148] pgd=0000000000000000, p4d=0000000000000000 [ 92.797381] Internal error: Oops: 0000000096000004 [#1] SMP [ 92.803027] Modules linked in: powervr [ 92.852533] CPU: 0 UID: 0 PID: 409 Comm: triangle Not tainted 7.1.0-rc5-g98b46e693b91 #1 PREEMPT [ 92.861385] Hardware name: Texas Instruments AM68 SK (DT) [ 92.866766] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 92.873709] pc : pvr_vm_get_fw_mem_context+0x0/0xc [powervr] [ 92.879376] lr : pvr_queue_create+0x26c/0x440 [powervr] [ 92.884595] sp : ffff8000837fbb00 [ 92.887895] x29: ffff8000837fbb60 x28: 0000000000000000 x27: ffff8000837fbce8 [ 92.895015] x26: ffff000807f61a40 x25: ffff000807f61a00 x24: ffff000807f64400 [ 92.902135] x23: ffff00080a5ab000 x22: ffff800079b24730 x21: ffff000807f61800 [ 92.909254] x20: ffff00080999e680 x19: 0000000000000000 x18: 0000000000000000 [ 92.916373] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000001 [ 92.923492] x14: 0000000000000000 x13: 0000000000000002 x12: ffff80008145b298 [ 92.930611] x11: ffff8000844e5000 x10: ffff80008165a130 x9 : 0000000000000100 [ 92.937730] x8 : 0000000000000001 x7 : ffff0008076b27e0 x6 : ffff00080ec43b7c [ 92.944850] x5 : ffff00080ec43b78 x4 : 0000000000000000 x3 : ffff00080999e680 [ 92.951968] x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 [ 92.959088] Call trace: [ 92.961521] pvr_vm_get_fw_mem_context+0x0/0xc [powervr] (P) [ 92.967173] pvr_context_create+0x190/0x410 [powervr] [ 92.972218] pvr_ioctl_create_context+0x44/0x8c [powervr] [ 92.977608] drm_ioctl_kernel+0xbc/0x124 [drm] [ 92.982127] drm_ioctl+0x1f8/0x4dc [drm] [ 92.986098] __arm64_sys_ioctl+0xac/0x104 [ 92.990102] invoke_syscall+0x54/0x10c [ 92.993842] el0_svc_common.constprop.0+0x40/0xe0 [ 92.998532] do_el0_svc+0x1c/0x28 [ 93.001835] el0_svc+0x38/0x11c [ 93.004969] el0t_64_sync_handler+0xa0/0xe4 [ 93.009139] el0t_64_sync+0x198/0x19c [ 93.012792] Code: aa1703e0 d2800014 95cb0ba4 17ffffe8 (f940a400) [ 93.018869] ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68262", "url": "https://ubuntu.com/security/CVE-2026-68262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: Fix user array stride in pvr_set_uobj_array() pvr_set_uobj_array() copies an array of kernel objects to a userspace array whose element size is described by out->stride. When out->stride is different from the kernel object size, the slow path advances the userspace pointer by the kernel object size and the kernel pointer by the userspace stride. This reverses the intended layout. For larger userspace strides, later copies read from the wrong kernel addresses. For smaller userspace strides, later copies are written at the wrong userspace offsets. The padding clear is also done only for the first element instead of the padding area for each element. Advance the userspace pointer by out->stride and the kernel pointer by obj_size, and clear per-element padding while the current userspace pointer is still available.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68263", "url": "https://ubuntu.com/security/CVE-2026-68263", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: Fix double call to drm_sched_entity_fini() Call sequence of double call: pvr_context_destroy   pvr_context_kill_queues     pvr_queue_kill       drm_sched_entity_destroy         drm_sched_entity_fini // here   pvr_context_put     kref_put(..., pvr_context_release)       pvr_context_destroy_queues         pvr_queue_destroy           drm_sched_entity_fini // here Call to drm_sched_entity_destroy() from pvr_context_kill_queues() calls drm_sched_entity_flush() + drm_sched_entity_fini(). drm_sched_entity_flush() ensures all pending jobs are completed and drm_sched_entity_fini() ensures no further submission is allowed as per expectation from pvr_context_kill_queues(). Double call to drm_sched_entity_fini() is misuse of the API so keep call only in pvr_context_create() failure path. Stack trace for issue with addition of refcounting for DRM entity stats in commit fd177135f0e6 (\"drm/sched: Account entity GPU time\"): [ 789.490527] ------------[ cut here ]------------ [ 789.490559] refcount_t: underflow; use-after-free. [ 789.490657] WARNING: lib/refcount.c:28 at refcount_warn_saturate+0xf4/0x144, CPU#0: kworker/u16:1/440 [ 789.490695] Modules linked in: powervr drm_gpuvm drm_exec gpu_sched drm_shmem_helper xhci_plat_hcd xhci_hcd dwc3 usbcore usb_common snd_soc_simple_card snd_soc_simple_card_utils sa2ul sha512 sha256 dwc3_am62 sha1 authenc rti_wdt libsha512 at24 sch_fq_codel fuse dm_mod ipv6 [ 789.490798] CPU: 0 UID: 0 PID: 440 Comm: kworker/u16:1 Not tainted 7.0.0-rc7-02049-g5e2c0700091b #22 PREEMPT [ 789.490809] Hardware name: Texas Instruments AM625 SK (DT) [ 789.490815] Workqueue: powervr-sched pvr_queue_fence_release_work [powervr] [ 789.490868] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 789.490876] pc : refcount_warn_saturate+0xf4/0x144 [ 789.490884] lr : refcount_warn_saturate+0xf4/0x144 [ 789.490892] sp : ffff8000822cbcc0 [ 789.490895] x29: ffff8000822cbcc0 x28: 0000000000000000 x27: 0000000000000000 [ 789.490909] x26: 0000000000000000 x25: ffff800081b1e338 x24: ffff000004541405 [ 789.490922] x23: ffff000004bea950 x22: ffff00000042e400 x21: ffff000007123e30 [ 789.490935] x20: ffff000007123000 x19: ffff000007a80d50 x18: fffffffffffe7768 [ 789.490948] x17: 74736574202c6e6f x16: 697461746e656d65 x15: ffff800081b269f0 [ 789.490962] x14: 0000000000000030 x13: ffff800081b26a70 x12: 0000000000000211 [ 789.490975] x11: 00000000000000c0 x10: 0000000000000b50 x9 : ffff8000822cbb30 [ 789.490988] x8 : ffff0000014e7bb0 x7 : ffff00007725e780 x6 : 0000000372a05f49 [ 789.491001] x5 : 0000000000000000 x4 : 0000000000000001 x3 : 0000000000000010 [ 789.491013] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000014e7000 [ 789.491027] Call trace: [ 789.491032] refcount_warn_saturate+0xf4/0x144 (P) [ 789.491043] drm_sched_entity_fini+0x164/0x18c [gpu_sched] [ 789.491081] pvr_queue_destroy+0x64/0x134 [powervr] [ 789.491110] pvr_context_destroy_queues+0x34/0x64 [powervr] [ 789.491138] pvr_context_release+0x70/0xac [powervr] [ 789.491166] pvr_context_put.part.0+0x5c/0x7c [powervr] [ 789.491193] pvr_context_put+0x14/0x24 [powervr] [ 789.491221] pvr_queue_fence_release_work+0x20/0x38 [powervr] [ 789.491249] process_one_work+0x160/0x4c4 [ 789.491264] worker_thread+0x188/0x310 [ 789.491276] kthread+0x130/0x13c [ 789.491287] ret_from_fork+0x10/0x20 [ 789.491300] ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68437", "url": "https://ubuntu.com/security/CVE-2026-68437", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: Fit paired fragment job in the correct CCCB For geometry jobs with a paired fragment job, at the moment, the DRM scheduler's prepare_job() callback: - checks for internal (driver) dependencies for the geometry job; - calls into pvr_queue_get_paired_frag_job_dep() to check for external dependencies for the fragment job (the two jobs are submitted together but the common scheduler code doesn't know about it, so this needs to be done at this point in time); - calls into the prepare_job() callback again, but for the fragment job, to check its internal dependencies as well, passing the fragment job's drm_sched_job and the geometry job's drm_sched_entity / pvr_queue. The problem with the last step is that pvr_queue_prepare_job() doesn't always take the mismatched fragment job and geometry queue into account, in particular when checking whether there is space for the fragment command to be submitted, so the code ends up checking for space in the geometry (i.e. wrong) CCCB. The rest of the nested prepare_job() callback happens to work fine at the moment as the other internal dependencies are not relevant for a paired fragment job. Move the initialisation of a paired fragment job's done fence and CCCB fence to pvr_queue_get_paired_frag_job_dep(), inferring the correct queue from the fragment job itself. This fixes cases where prepare_job() wrongly assumed that there was enough space for a paired fragment job in its own CCCB, unblocking run_job(), which then returned early without writing the full sequence of commands to the CCCB. The above lead to kernel warnings such as the following and potentially job timeouts (depending on waiters on the missing commands): [ 552.421075] WARNING: drivers/gpu/drm/imagination/pvr_cccb.c:178 at pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr], CPU#2: kworker/u16:5/63 [ 552.421230] Modules linked in: [ 552.421592] CPU: 2 UID: 0 PID: 63 Comm: kworker/u16:5 Tainted: G W 7.0.0-rc2-gc5d053e4dccb #39 PREEMPT [ 552.421625] Tainted: [W]=WARN [ 552.421637] Hardware name: Texas Instruments AM625 SK (DT) [ 552.421655] Workqueue: powervr-sched drm_sched_run_job_work [gpu_sched] [ 552.421744] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 552.421766] pc : pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr] [ 552.421850] lr : pvr_queue_submit_job_to_cccb+0x57c/0xa74 [powervr] [ 552.421923] sp : ffff800084c47650 [ 552.421936] x29: ffff800084c47740 x28: 0000000000000df8 x27: ffff800088a77000 [ 552.421979] x26: 0000000000000030 x25: ffff800084c47680 x24: 0000000000001000 [ 552.422017] x23: ffff800084c47820 x22: 1ffff00010988ecc x21: 0000000000000008 [ 552.422055] x20: 0000000000000208 x19: ffff000006ad5a88 x18: 0000000000000000 [ 552.422093] x17: 0000000020020000 x16: 0000000000020000 x15: 0000000000000000 [ 552.422130] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 [ 552.422167] x11: 000000000000f2f2 x10: 00000000f3000000 x9 : 00000000f3f3f3f3 [ 552.422204] x8 : 00000000f2f2f200 x7 : ffff700010988ecc x6 : 0000000000000008 [ 552.422241] x5 : 0000000000000000 x4 : 1ffff0001114ee00 x3 : 0000000000000000 [ 552.422278] x2 : 0000000000000007 x1 : 0000000000000fff x0 : 000000000000002f [ 552.422316] Call trace: [ 552.422330] pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr] (P) [ 552.422411] pvr_queue_submit_job_to_cccb+0x57c/0xa74 [powervr] [ 552.422486] pvr_queue_run_job+0x3a4/0x990 [powervr] [ 552.422562] drm_sched_run_job_work+0x580/0xd48 [gpu_sched] [ 552.422623] process_one_work+0x520/0x1288 [ 552.422657] worker_thread+0x3f0/0xb3c [ 552.422679] kthread+0x334/0x3d8 [ 552.422706] ret_from_fork+0x10/0x20", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68281", "url": "https://ubuntu.com/security/CVE-2026-68281", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: Count paired job fence as dependency in prepare_job() The DRM scheduler's prepare_job() callback counts the remaining non-signaled native dependencies for a job, preventing job submission until those (plus job data and fence update) can fit in the job queue's CCCB. This means checking which dependencies can be waited upon in the firmware, i.e. whether they are backed by a UFO object, i.e. whether their drm_sched_fence::parent has been assigned to a pvr_queue_fence::base fence. That happens when the job owning the fence is submitted to the firmware. Paired geometry and fragment jobs are submitted at the same time, which means the dependency between them can't be checked this way before submission. Update job_count_remaining_native_deps() to take into account the dependency between paired jobs. This fixes cases where prepare_job() underestimated the space left in an almost full fragment CCCB, wrongly unblocking run_job(), which then returned early without writing the full sequence of commands to the CCCB. The above lead to kernel warnings such as the following and potentially job timeouts (depending on waiters on the missing commands): [ 375.702979] WARNING: drivers/gpu/drm/imagination/pvr_cccb.c:178 at pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr], CPU#1: kworker/u16:3/47 [ 375.703160] Modules linked in: [ 375.703571] CPU: 1 UID: 0 PID: 47 Comm: kworker/u16:3 Tainted: G W 7.0.0-rc2-g817eb6b11ad5 #40 PREEMPT [ 375.703613] Tainted: [W]=WARN [ 375.703627] Hardware name: Texas Instruments AM625 SK (DT) [ 375.703645] Workqueue: powervr-sched drm_sched_run_job_work [gpu_sched] [ 375.703741] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 375.703764] pc : pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr] [ 375.703847] lr : pvr_queue_submit_job_to_cccb+0x578/0xa70 [powervr] [ 375.703921] sp : ffff800084a97650 [ 375.703934] x29: ffff800084a97740 x28: 0000000000000958 x27: ffff80008565d000 [ 375.703979] x26: 0000000000000030 x25: ffff800084a97680 x24: 0000000000001000 [ 375.704017] x23: ffff800084a97820 x22: 1ffff00010952ecc x21: 0000000000000008 [ 375.704056] x20: 00000000000006a8 x19: ffff00002ff7da88 x18: 0000000000000000 [ 375.704093] x17: 0000000020020000 x16: 0000000000020000 x15: 0000000000000000 [ 375.704132] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 [ 375.704168] x11: 000000000000f2f2 x10: 00000000f3000000 x9 : 00000000f3f3f3f3 [ 375.704206] x8 : 00000000f2f2f200 x7 : ffff700010952ecc x6 : 0000000000000008 [ 375.704243] x5 : 0000000000000000 x4 : 1ffff00010acba00 x3 : 0000000000000000 [ 375.704279] x2 : 0000000000000007 x1 : 0000000000000fff x0 : 000000000000002f [ 375.704317] Call trace: [ 375.704331] pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr] (P) [ 375.704411] pvr_queue_submit_job_to_cccb+0x578/0xa70 [powervr] [ 375.704487] pvr_queue_run_job+0x3a4/0x990 [powervr] [ 375.704562] drm_sched_run_job_work+0x580/0xd48 [gpu_sched] [ 375.704623] process_one_work+0x520/0x1288 [ 375.704658] worker_thread+0x3f0/0xb3c [ 375.704680] kthread+0x334/0x3d8 [ 375.704706] ret_from_fork+0x10/0x20 [ 375.704736] ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68290", "url": "https://ubuntu.com/security/CVE-2026-68290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rds: tcp: unregister sysctl before tearing down listen socket rds_tcp_exit_net() frees the per-netns RDS TCP listen socket via rds_tcp_kill_sock() before unregistering the per-netns sysctl table. Since rds_tcp_skbuf_handler() derives the netns from rtn->rds_tcp_listen_sock->sk, a concurrent sysctl write can race with netns teardown and dereference the freed socket/sk. KASAN reports the race as: BUG: KASAN: slab-use-after-free in rds_tcp_skbuf_handler+0x2aa/0x2e0 rds_tcp_skbuf_handler net/rds/tcp.c:721 proc_sys_call_handler fs/proc/proc_sysctl.c vfs_write fs/read_write.c __x64_sys_pwrite64 fs/read_write.c Fix this by unregistering the RDS TCP sysctl table before calling rds_tcp_kill_sock(). unregister_net_sysctl_table() prevents new sysctl handlers from starting and waits for in-flight handlers to finish, so the listen socket can then be released safely. The fix was tested against the linked reproducer.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68293", "url": "https://ubuntu.com/security/CVE-2026-68293", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix MCIA register buffer overflow on 32 dword reads The MCIA register can return up to 32 dwords (128 bytes) when the device advertises the mcia_32dwords capability, but struct mlx5_ifc_mcia_reg_bits only defines dword_0..11, leaving room for just 12 dwords (48 bytes) of data. mlx5_query_mcia() clamps the read size to mlx5_mcia_max_bytes() and then memcpy()s that many bytes out of the register, potentially reading past the end of the 'out' buffer. On kernels built with FORTIFY_SOURCE this is caught as a buffer overflow while reading the module EEPROM via ethtool: detected buffer overflow in memcpy kernel BUG at lib/string_helpers.c:1048! RIP: 0010:fortify_panic+0x13/0x20 Call Trace: mlx5_query_mcia.isra.0+0x200/0x210 [mlx5_core] mlx5_query_module_eeprom_by_page+0x4a/0xa0 [mlx5_core] mlx5e_get_module_eeprom_by_page+0xbb/0x120 [mlx5_core] eeprom_prepare_data+0xf3/0x170 ethnl_default_doit+0xf1/0x3b0 Extend the mcia_reg layout to 32 dwords.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68439", "url": "https://ubuntu.com/security/CVE-2026-68439", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7925: fix possible NULL-pointer deref in mt7925_mcu_bss_he_tlv() mt76_connac_get_he_phy_cap routine can theoretically return NULL so check cap pointer before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68314", "url": "https://ubuntu.com/security/CVE-2026-68314", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mctp i3c: clean up notifier and buses if driver register fails mctp_i3c_mod_init() registers the I3C bus notifier and then walks the existing buses with i3c_for_each_bus_locked(mctp_i3c_bus_add_new, NULL) before registering the I3C device driver. If i3c_driver_register() fails, the function returns the error directly, leaving the notifier registered and every mctp_i3c_bus object created for the existing buses allocated. The notifier is left pointing into the module that failed to load and the bus list is leaked. Mirror the module exit path on this failure: unregister the notifier and tear down the buses that were added before returning the error. This issue was identified during our ongoing static-analysis research while reviewing kernel code.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68318", "url": "https://ubuntu.com/security/CVE-2026-68318", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pds_core: fix use-after-free on workqueue during remove In pdsc_remove(), the workqueue is destroyed before pdsc_teardown() is called. This ordering allows two paths to queue work on the destroyed workqueue: 1. If pdsc_teardown() -> pdsc_devcmd_reset() times out, the error path in pdsc_devcmd_locked() queues health_work. 2. A NotifyQ event can trigger the ISR and queue work before free_irq() is called in pdsc_teardown(). Fix by moving destroy_workqueue() after pdsc_teardown() so the workqueue outlives every queuer; destroy_workqueue() then flushes any work still pending. Draining the queued work also requires ordering the teardown so the resources that work touches are freed last: - In pdsc_qcq_free(), after freeing the interrupt, cancel_work_sync() the queue's work and only then clear qcq->intx, so pdsc_process_adminq()'s read of qcq->intx for interrupt-credit return cannot race with the clear. - Free adminqcq before notifyqcq: the shared adminq ISR is released when adminqcq is freed, and the adminq work accesses notifyqcq, so both must be stopped before notifyqcq is freed.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68319", "url": "https://ubuntu.com/security/CVE-2026-68319", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pds_core: fix deadlock between reset thread and remove pci_reset_function() acquires device_lock before performing the reset. pdsc_remove() is called by the PCI core with device_lock already held. If pdsc_pci_reset_thread() is running when pdsc_remove() is called, destroy_workqueue() will block waiting for the work to complete, while the work is blocked waiting for device_lock - deadlock. Use pci_try_reset_function() which uses pci_dev_trylock() internally. This acquires both the device lock and the PCI config access lock without blocking - if either lock is contended, it returns -EAGAIN immediately. This avoids the deadlock while also ensuring proper config space access serialization during the reset. The pci_dev_get/put calls are also removed as they were unnecessary - the driver-owned workqueue is destroyed in pdsc_remove(), guaranteeing the work completes before remove returns. The PCI core holds its reference to pci_dev throughout the entire unbind sequence.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68346", "url": "https://ubuntu.com/security/CVE-2026-68346", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: hda: cs35l41: validate and free ACPI mute object cs35l41_get_acpi_mute_state() evaluates a _DSM method to get the ACPI mute state and reads the first byte from the returned object. However, the returned ACPI object is owned by the caller and is never freed after use, so each successful query leaks the _DSM result object. The code also assumes that the returned object is a buffer with at least one byte. A malformed firmware response can return a different object type or an empty buffer, and the direct ret->buffer.pointer dereference can then access an invalid pointer. Use the typed _DSM helper, validate that the returned buffer contains at least one byte, and free the ACPI object after reading it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2025-40098", "url": "https://ubuntu.com/security/CVE-2025-40098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: hda: cs35l41: Fix NULL pointer dereference in cs35l41_get_acpi_mute_state() Return value of a function acpi_evaluate_dsm() is dereferenced without checking for NULL, but it is usually checked for this function. acpi_evaluate_dsm() may return NULL, when acpi_evaluate_object() returns acpi_status other than ACPI_SUCCESS, so add a check to prevent the crach. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-10-30 10:15:00 UTC" }, { "cve": "CVE-2026-68442", "url": "https://ubuntu.com/security/CVE-2026-68442", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: don't propagate EXTENT_FLAG_LOGGING to split extent maps When btrfs_drop_extent_map_range() splits an extent map, the new split maps inherit the original map's flags through a local 'flags' variable. Commit f86f7a75e2fb (\"btrfs: use the flags of an extent map to identify the compression type\") changed the EXTENT_FLAG_LOGGING clearing to operate on em->flags instead of that local 'flags' copy, so a split of an extent map that is currently being logged wrongly inherits EXTENT_FLAG_LOGGING. The flag is then never cleared on the split, and when it is freed while still on the inode's modified_extents list (for example by the extent map shrinker) it trips the WARN_ON(!list_empty(&em->list)) in btrfs_free_extent_map() and leads to a use-after-free. Clear EXTENT_FLAG_LOGGING from the local 'flags' copy used for the splits and only clear EXTENT_FLAG_PINNED from em->flags, restoring the behaviour prior to f86f7a75e2fb.", "cve_priority": "high", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68443", "url": "https://ubuntu.com/security/CVE-2026-68443", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (gigabyte_waterforce) Stop device IO before calling hid_hw_stop Calling hid_hw_stop() does not stop the device IO. This results in a race condition between hid_input_report() and the point immediately following the execution of hid_device_io_start() within the driver probe function. If the probe operation fails after \"io start\" has been initiated, this race condition will result in a UAF vulnerability. Fix the problem by calling hid_device_io_stop() before calling hid_hw_stop().", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68372", "url": "https://ubuntu.com/security/CVE-2026-68372", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: core: port: Deattach Type-C connector on component unbind connector_unbind() is the mirror of connector_bind(), but it is missing the symmetric call to typec_deattach() that connector_bind() makes via: if (port_dev->child) typec_attach(port_dev->connector, &port_dev->child->dev); When a Thunderbolt dock is unplugged, two teardown paths race: 1. The component framework calls connector_unbind() first, which sets port_dev->connector = NULL without calling typec_deattach(). This leaves port->usb2_dev/port->usb3_dev in struct typec_port pointing at the USB device that is about to be freed. 2. usb_disconnect() then calls typec_deattach(port_dev->connector, ...), but port_dev->connector is already NULL, so the call is a no-op and port->usb2_dev is never cleared. 3. Concurrently, UCSI detects a PD partner-disconnect event and calls typec_unregister_partner(), which reads port->usb2_dev (now a dangling pointer to freed memory) and passes it to typec_partner_unlink_device() -> sysfs_remove_link() -> dev_name() on the freed device, corrupting the typec/UCSI partner state. This corruption leaves the Thunderbolt tunnel in an inconsistent state on the next dock hot-plug. On affected hardware the dock's I225/igc NIC fails to enumerate: AER fires a slot reset while the igc driver is still initialising (\"PCIe link lost\"), and the subsequent igc_reset attempt hits igc_rd32 on an already-detached device: igc 0000:2e:00.0 eth0: PCIe link lost, device now detached igc: Failed to read reg 0x0! WARNING: CPU: 9 PID: 129 at drivers/net/ethernet/intel/igc/igc_main.c:7005 igc_rd32+0xa4/0xc0 [igc] Call Trace: igc_disable_pcie_master+0x16/0xa0 [igc] igc_reset_hw_base+0x14/0x170 [igc] igc_reset+0x63/0x110 [igc] igc_io_slot_reset+0x9e/0xd0 [igc] report_slot_reset+0x5d/0xc0 pcie_do_recovery+0x209/0x400 aer_isr_one_error_type+0x235/0x430 aer_isr+0x4e/0x80 irq_thread+0xf4/0x1f0 4. UCSI later handles the PD partner-disconnect and calls typec_unregister_partner(), which still sees the stale port->usb2_dev and tries to remove its sysfs link a second time: kernfs: can not remove 'typec', no directory WARNING: CPU: 6 PID: 55 at fs/kernfs/dir.c:1706 kernfs_remove_by_name_ns+0xe9/0xf0 Workqueue: events ucsi_handle_connector_change [typec_ucsi] Call Trace: sysfs_remove_link+0x19/0x50 typec_unregister_partner+0x6e/0x120 [typec] ucsi_unregister_partner+0x107/0x150 [typec_ucsi] ucsi_handle_connector_change+0x3ec/0x490 [typec_ucsi] process_one_work+0x18e/0x3e0 worker_thread+0x2e3/0x420 kthread+0x10a/0x230 ret_from_fork+0x121/0x140 ret_from_fork_asm+0x1a/0x30 With worse timing the same stale pointer is dereferenced after the backing memory is freed, turning the warning into a use-after-free. Fix the asymmetry: call typec_deattach() before clearing port_dev->connector, matching what connector_bind() does on the bind side. typec_partner_deattach() is already protected by port->partner_link_lock, so it serialises safely with the concurrent typec_unregister_partner() path.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68396", "url": "https://ubuntu.com/security/CVE-2026-68396", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: core: wake eh reliably when using scsi_schedule_eh Drivers which use the scsi_schedule_eh function to run the error handler currently risk the error handler thread never waking once all commands are timed out or inactive. There is no enforced memory order between setting the host into error recovery state and counting busy commands. This can result in a race with scsi_dec_host_busy where neither CPU sees both conditions of all commands inactive and the host error state to request waking the error handler. To fix this, run the scsi_schedule_eh's scsi_eh_wakeup from a new work item which will use rcu to ensure scsi_schedule_eh's call to scsi_host_busy will occur after the error state is globally visible and will be seen by any current scsi_dec_host_busy callers.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68408", "url": "https://ubuntu.com/security/CVE-2026-68408", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: convert pmsr_free_wk to wiphy_work to fix deadlock When a netlink socket that owns a PMSR session is closed, cfg80211_release_pmsr() clears the request's nl_portid and queues pmsr_free_wk to call cfg80211_pmsr_process_abort() asynchronously. If the interface tears down concurrently, cfg80211_pmsr_wdev_down() is called under wiphy_lock and calls cancel_work_sync(&pmsr_free_wk) to wait for any running work. The work function acquires wiphy_lock via guard(wiphy) before calling process_abort. This is a deadlock: wdev_down holds wiphy_lock and blocks inside cancel_work_sync(); pmsr_free_wk blocks trying to acquire that same wiphy_lock. Neither thread can proceed. The same deadlock is reachable from cfg80211_leave_locked(), which calls cfg80211_pmsr_wdev_down() for all interface types under wiphy_lock. Fix this by converting pmsr_free_wk from a plain work_struct to a wiphy_work. The wiphy_work dispatcher holds wiphy_lock when running work items, so the explicit guard(wiphy) in the work function is no longer needed. wiphy_work_cancel() can be called safely while holding wiphy_lock - since wiphy_lock prevents the work from running concurrently, wiphy_work_cancel() never blocks, eliminating the deadlock. Remove the cancel_work_sync() for pmsr_free_wk from the NETDEV_GOING_DOWN handler. cfg80211_leave(), called unconditionally just before it, already cancels any pending work under wiphy_lock via wiphy_work_cancel() inside cfg80211_pmsr_wdev_down().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64570", "url": "https://ubuntu.com/security/CVE-2026-64570", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: fix fils_discovery double free on alloc failure ieee80211_set_fils_discovery() calls kfree_rcu() on the old template before allocating the replacement. If the kzalloc() then fails, it returns -ENOMEM while link->u.ap.fils_discovery still points at the object already queued for freeing. A later update or AP teardown (ieee80211_stop_ap()) re-queues that same rcu_head; the second free is caught by KASAN when the RCU sheaf is processed in softirq: BUG: KASAN: double-free in rcu_free_sheaf (mm/slub.c:5850) Free of addr ffff88800c065280 by task swapper/0/0 ... __rcu_free_sheaf_prepare (mm/slub.c:2634 mm/slub.c:2940) rcu_free_sheaf (mm/slub.c:5850) rcu_core (kernel/rcu/tree.c:2617 kernel/rcu/tree.c:2869) handle_softirqs (kernel/softirq.c:622) The buggy address belongs to the cache kmalloc-96 of size 96 Queue the old object for kfree_rcu() only after the new one is published, matching ieee80211_set_probe_resp() and ieee80211_set_s1g_short_beacon().", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-64568", "url": "https://ubuntu.com/security/CVE-2026-64568", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: fix unsol_bcast_probe_resp double free on alloc failure ieee80211_set_unsol_bcast_probe_resp() calls kfree_rcu() on the old template before allocating the replacement. If the kzalloc() then fails, it returns -ENOMEM while link->u.ap.unsol_bcast_probe_resp still points at the object already queued for freeing. A later update or AP teardown re-queues that same rcu_head; the second free is caught by KASAN when the RCU sheaf is processed in softirq: BUG: KASAN: double-free in rcu_free_sheaf (mm/slub.c:5850) Free of addr ffff88800d06f300 by task exploit/145 ... __rcu_free_sheaf_prepare (mm/slub.c:2634 mm/slub.c:2940) rcu_free_sheaf (mm/slub.c:5850) rcu_core (kernel/rcu/tree.c:2617 kernel/rcu/tree.c:2869) handle_softirqs (kernel/softirq.c:622) The buggy address belongs to the cache kmalloc-128 of size 128 Queue the old object for kfree_rcu() only after the new one is published, matching ieee80211_set_probe_resp() and ieee80211_set_s1g_short_beacon().", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-72175", "url": "https://ubuntu.com/security/CVE-2026-72175", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/proc/task_mmu: fix make_uffd_wp_huge_pte() prot-update race Patch series \"userfaultfd/pagemap: pre-existing fixes\". These are pre-existing bug fixes that were carried at the front of the userfaultfd RWP working-set-tracking series up to v5 [1]. Per review feedback that fixes should not sit in the middle of a feature series, they are split out and sent on their own; the RWP series is reposted rebased on top of this. All six were flagged by the Sashiko AI review of the RWP series and carry independent of RWP, apply to mm-new directly, and carry Cc: stable@. 1: fs/proc/task_mmu: a missing huge_ptep_modify_prot_start() in make_uffd_wp_huge_pte() can lose hardware Dirty/Accessed updates when PAGEMAP_SCAN write-protects a hugetlb PTE. 2: fs/proc/task_mmu: pagemap_scan_hugetlb_entry() compares the range against HPAGE_SIZE rather than the hstate page size, so it never write-protects gigantic hugetlb pages. 3: fs/proc/task_mmu: PAGEMAP_SCAN with PM_SCAN_WP_MATCHING over an unpopulated hugetlb range self-deadlocks -- pagemap_scan_pte_hole() calls uffd_wp_range() while walk_hugetlb_range() holds the hugetlb vma lock for read, and hugetlb_change_protection() then takes it for write. Install the marker inline instead. 4: mm/huge_memory: change_non_present_huge_pmd() drops pmd_swp_uffd_wp on a device-private PMD permission downgrade, silently losing the uffd-wp marker. 5: userfaultfd: must_wait() applies pte_write() to a locklessly read PTE without checking pte_present(), so swap/migration entries decode random offset bits and a thread can stay parked on a stale fault. 6: userfaultfd: __VMA_UFFD_FLAGS feeds VMA_UFFD_MINOR_BIT (41) to mk_vma_flags() unconditionally, an out-of-bounds write into the single-word vma_flags_t on 32-bit. Build the mask from config-gated per-mode masks so an unavailable bit is never materialised. This patch (of 6): make_uffd_wp_huge_pte() arms the UFFD_WP bit on a present HugeTLB PTE by calling huge_ptep_modify_prot_commit() with a ptent snapshot that was fetched without the corresponding huge_ptep_modify_prot_start(). The start helper is what atomically clears the entry so the kernel-owned snapshot stays consistent until the commit; without it, the hardware may set Dirty or Accessed in the live PTE between the original read and the commit, and huge_ptep_modify_prot_commit() (whose generic implementation just calls set_huge_pte_at()) then writes the stale snapshot back over the live hardware bits, losing the update. The non-hugetlb sibling make_uffd_wp_pte() does this correctly via ptep_modify_prot_start() / ptep_modify_prot_commit(). Mirror that pattern for the present-PTE branch. The migration case stays as-is -- migration entries are non-present, so there's no hardware update to race against.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-45901", "url": "https://ubuntu.com/security/CVE-2026-45901", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: revert commit_mutex usage in reset path It causes circular lock dependency between commit_mutex, nfnl_subsys_ipset and nlk_cb_mutex when nft reset, ipset list, and iptables-nft with '-m set' rule run at the same time. Previous patches made it safe to run individual reset handlers concurrently so commit_mutex is no longer required to prevent this.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45897", "url": "https://ubuntu.com/security/CVE-2026-45897", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_counter: serialize reset with spinlock Add a global static spinlock to serialize counter fetch+reset operations, preventing concurrent dump-and-reset from underrunning values. The lock is taken before fetching the total so that two parallel resets cannot both read the same counter values and then both subtract them. A global lock is used for simplicity since resets are infrequent. If this becomes a bottleneck, it can be replaced with a per-net lock later.", "cve_priority": "low", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-68093", "url": "https://ubuntu.com/security/CVE-2026-68093", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: SVM: Bump asid_generation on CPU online to avoid ASID collision after hotplug If a vCPU stays scheduled out (or blocked) while the last pCPU it ran on goes through a hotplug cycle (online->offline->online), and the vCPU then resumes execution on the same pCPU, then it is possible for it to run with an ASID that has now been assigned to a different vCPU, resulting in stale TLB translations being used. svm_enable_virtualization_cpu() resets asid_generation to 1 and sets next_asid to max_asid + 1 on every CPU online event, including hotplug cycles. Because next_asid starts beyond the pool boundary, the first call to new_asid() after an online event always wraps the pool, incrementing asid_generation to 2 and assigning ASIDs starting from min_asid. Consider two vCPUs from different VMs, vCPU-A pinned to CPU-X holding asid_generation=2 and ASID=N from before the hotplug event: 1. CPU-X goes offline and back online: asid_generation resets to 1, next_asid = max_asid + 1. 2. One or more vCPUs migrate to CPU-X and call new_asid(), wrapping the pool and consuming ASIDs starting from min_asid. Eventually vCPU-B from a different VM is assigned asid_generation=2, ASID=N — the same ASID that vCPU-A held before the hotplug. 3. vCPU-A enters pre_svm_run() on CPU-X: current_vmcb->cpu is unchanged so the migration branch is skipped. Its saved asid_generation=2 matches sd->asid_generation=2, so the generation check silently passes and vCPU-A continues running with ASID=N — the same ASID just freshly assigned to vCPU-B. Both vCPUs from different VMs now run on CPU-X with the same ASID, causing them to share NPT TLB entries and producing stale translations. The collision manifests as a KVM internal error (Suberror: 1, emulation failure). The NPT page fault reports a faulting GPA far outside the VM's physical memory range — a sign of stale TLB translations being used. KVM falls back to instruction emulation, which fails on FPU/XSave instructions (XRSTOR, STMXCSR) that the emulator does not implement. Fix this by incrementing asid_generation instead of resetting it to 1 in svm_enable_virtualization_cpu(). On module load, asid_generation starts at 0 (memset) and the increment produces 1, identical to the old behaviour. On subsequent hotplug cycles the generation advances beyond any value a vCPU previously observed on this CPU, so the generation check in pre_svm_run() reliably forces new_asid() on every vCPU after every hotplug cycle.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68164", "url": "https://ubuntu.com/security/CVE-2026-68164", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/damon/core: disallow overlapping input ranges for damon_set_regions() damon_set_regions() assumes the input ranges are sorted by the address and don't overlap each other. Hence the assumption was initially to be explicitly validated. But commit 97d482f4592f (\"mm/damon/sysfs: reuse damon_set_regions() for regions setting\") has mistakenly removed the validation. This can make DAMON behave in unexpected ways. At the best, the monitoring results snapshot will just look weird since there will be overlapping regions. DAMOS will also work weirdly, applying the same action multiple times for overlapping regions, and make DAMOS quota weird. More seriously, depending on the setup and regions updates sequence, negative size regions can be made. It will trigger WARN_ONCE() if the kernel is built with CONFIG_DAMON_DEBUG_SANITY=y. Depending on the monitoring results, the negative size region can further trigger division by zero in damon_merge_two_regions(). Note that some of the consequences including the WARN_ONCE() and the divide by zero depend on commits that were introduced after the root cause commit 97d482f4592f (\"mm/damon/sysfs: reuse damon_set_regions() for regions setting\"). Fix the problems by checking the assumption and returning an error if the input ranges don't meet the assumption. The issue was discovered [1] by Sashiko.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68165", "url": "https://ubuntu.com/security/CVE-2026-68165", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/damon/core: validate ranges in damon_set_regions() DAMON core logic assumes zero length regions don't exist. However, a few DAMON API callers including DAMON_SYSFS, DAMON_RECLAIM and DAMON_LRU_SORT allow users to set empty monitoring target regions. This could result in WARN_ONCE() on CONFIG_DAMON_DEBUG_SANITY enabled kernel, and divide-by-zero from damon_merge_two_regions(). For example, the WANR_ONCE() can be triggered like below. # grep DAMON_DEBUG_SANITY /boot/config-$(uname -r) # CONFIG_DAMON_DEBUG_SANITY=y # damo start # cd /sys/kernel/mm/damon/admin/kdamonds/0 # echo 0 > contexts/0/targets/0/regions/0/start # echo 0 > contexts/0/targets/0/regions/0/end # echo commit > state # dmesg [....] [ 73.705780] ------------[ cut here ]------------ [ 73.707552] start 0 >= end 0 [ 73.708452] WARNING: mm/damon/core.c:359 at damon_new_region+0x6e/0x80, CPU#1: kdamond.0/758 [...] All DAMON API callers eventually use damon_set_regions() to setup the regions. Add the validation logic in the function.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-72015", "url": "https://ubuntu.com/security/CVE-2026-72015", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/resctrl: Fix double-add of pseudo-locked region's RMID to free list A pseudo-locked group's RMID is freed when it is created. On unmount rmdir_all_sub() unconditionally frees all RMID of all groups, resulting in a double-free of the pseudo-locked group's RMID. The consequence of this is that the original free results in the pseudo-locked group's RMID being added to the rmid_free_lru linked list and the second free then attempts to add the same RMID entry to the rmid_free_lru again. Do not double-free a pseudo-locked group's RMID.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72017", "url": "https://ubuntu.com/security/CVE-2026-72017", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: macb: drop in-flight Tx SKBs on close The MACB driver has since forever leaked the outgoing SKBs that have not yet been marked as completed. They live in queue->tx_skb which gets freed without remorse nor checking. macb_free_consistent() gets called in a few codepaths, but only close will trigger the added expressions. In macb_open() and macb_alloc_consistent() failure cases, queues' tx_skb just got allocated and are empty.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72030", "url": "https://ubuntu.com/security/CVE-2026-72030", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ata: libata-core: Reject an invalid concurrent positioning ranges count ata_dev_config_cpr() takes the number of range descriptors from buf[0] of the concurrent positioning ranges log (up to 255), which the device reports independently of the log size in the GPL directory. The count is then walked at a fixed 32-byte stride in two places with no bound: the log read here, and the INQUIRY VPD page B9h emitter, which writes one descriptor per range into the fixed 2048-byte ata_scsi_rbuf. A device reporting a count larger than its own log overflows the read buffer (up to 7704 bytes past a 512-byte slab), and a count above 62 overflows the response buffer on the emit side. Bound the count once, on probe, against both the log the device returned and the number of descriptors the VPD B9h response buffer can hold (ATA_DEV_MAX_CPR, derived from the rbuf size). Reject an out-of-range count with a warning; this keeps the emitter in bounds with no separate change there.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72023", "url": "https://ubuntu.com/security/CVE-2026-72023", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: octeontx2-pf: fix SQB pointer leak on init failure otx2_init_hw_resources() initializes SQ aura and pool resources before several later setup steps. On failure, err_free_sq_ptrs only frees SQB pages, leaving the per-SQ sqb_ptrs arrays behind. Use otx2_free_sq_res() for the SQ unwind path and let it free sqb_ptrs even when sq->sqe has not been allocated yet. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in v7.1.1. An x86_64 allyesconfig build showed no new warnings. As we do not have an OcteonTX2 PF device and the corresponding AF mailbox setup to test with, no runtime testing was able to be performed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72040", "url": "https://ubuntu.com/security/CVE-2026-72040", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipmi: fix refcount leak in i_ipmi_request() When a caller provides a `supplied_recv` message to i_ipmi_request(), the function increments the user's `nr_msgs` reference count. If an error occurs later, the out_err cleanup path only frees the recv_msg if the function allocated it itself (i.e., !supplied_recv). In the supplied_recv case the cleanup is skipped, leaving the reference count elevated. The caller ipmi_request_supply_msgs() does not release the supplied_recv on error, so the reference is permanently leaked. Fix this by explicitly reverting the reference count operations when a supplied recv_msg with a valid user pointer is present in the error path: decrement nr_msgs and drop the user's kref.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72045", "url": "https://ubuntu.com/security/CVE-2026-72045", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: octeontx2-af: cn10k: restrict VF LMTLINE sharing to its own PF rvu_mbox_handler_lmtst_tbl_setup() uses req->base_pcifunc as a direct index into the LMT map table to read another function's LMTLINE physical base address and copy it into the caller's own LMT map table entry. The mailbox dispatcher authenticates req->hdr.pcifunc from the IRQ source, but req->base_pcifunc is a separate payload field and is not sanitized. Reject the request with -EPERM when a VF caller's base_pcifunc is not a valid function under its own PF. is_pf_func_valid() bounds the FUNC field to the PF's configured VF count, keeping the computed index inside the caller's own slot block.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72062", "url": "https://ubuntu.com/security/CVE-2026-72062", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpio: mt7621: avoid corruption of shared interrupt trigger state The bank-shared fields like 'rising' and 'falling' are modified using non-atomic read-modify-write operations. Since every gpio chip instance represents an entire bank of 32 pins, if 'mediatek_gpio_irq_type()' is called concurrently for different IRQs on the same bank a possible overwrite of each other's configuration is possible. Thus, protect this state with 'gpio_generic_lock_irqsave' lock in the same way it is handled in irp_chip 'mediatek_gpio_irq_mask()' and 'mediatek_gpio_irq_unmask()' callbacks.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72051", "url": "https://ubuntu.com/security/CVE-2026-72051", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ip6_tunnel: require CAP_NET_ADMIN in the device netns for changelink ip6_tnl_changelink() operates on at most two netns, dev_net(dev) and the tunnel link netns t->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in t->net can rewrite a tunnel that lives in t->net. Gate ip6_tnl_changelink() on rtnl_dev_link_net_capable() at its top, before any attribute is parsed.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72065", "url": "https://ubuntu.com/security/CVE-2026-72065", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mana: Validate the packet length reported by the NIC Validate the packet length reported in the RX CQE before passing it to skb processing. The CQE is supplied by the NIC device and should not be blindly trusted.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72069", "url": "https://ubuntu.com/security/CVE-2026-72069", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: locking/rt: Fix the incorrect RCU protection in rt_spin_unlock() rt_spin_unlock() releases the RCU protection before unlocking the lock. That opens the door for the following UAF scenario: T1\t\t\t\t\tT2 spin_lock(&p->lock);\t\trcu_read_lock(); invalidate(p);\t\t\tp = rcu_dereference(ptr); rcu_assign_pointer(ptr, NULL);\tif (!p) return; spin_unlock(&p->lock);\t\tspin_lock(&p->lock) \t\t\t\t lock(&lock->lock); \t\t\t\t rcu_read_lock(); kfree_rcu(p);\t\t\trcu_read_unlock(); \t\t\t\t.... \t\t\t\tspin_unlock(&p->lock) \t\t\t\t rcu_read_unlock(); // Ends grace period rcu_do_batch() kfree(p); \t\t\t UAF ->\t rt_mutex_cmpxchg_release(&lock->lock...) Regular spinlocks keep preemption disabled accross the unlock operation, which provides full RCU protection, but the RT substitution fails to resemble that. Same applies for the rwlock substitution. Move the rcu_read_unlock() invocation past the unlock operations to match the non-RT semantics. This makes it asymmetric vs. rt_xxx_lock(), but that's harmless as the caller needs to hold RCU read lock across the lock operation. The migrate_enable() call stays before the unlock operation because there is no per CPU operation in the unlock path which would require migration to be kept disabled.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72070", "url": "https://ubuntu.com/security/CVE-2026-72070", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: libertas_tf: fix use-after-free in lbtf_free_adapter() lbtf_free_adapter() calls timer_delete(&priv->command_timer), which does not wait for a running command_timer_fn() callback. lbtf_free_adapter() runs on the teardown path right before ieee80211_free_hw() frees priv, both in lbtf_remove_card() and in the probe error path. command_timer is armed by mod_timer() in lbtf_cmd() whenever a firmware command is sent. command_timer_fn() dereferences priv. If a command times out as the device is removed, command_timer_fn() runs concurrently with teardown and dereferences priv after it has been freed. This is the same use-after-free that commit 03cc8f90d053 (\"wifi: libertas: fix use-after-free in lbs_free_adapter()\") fixed in the sibling libertas driver. The libertas_tf variant has the identical pattern and was left unchanged. Use timer_delete_sync() so any in-flight callback completes before priv is freed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72142", "url": "https://ubuntu.com/security/CVE-2026-72142", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: imx: fix locked bus on SMBus block-read of 0 (atomic) SMBus 3.1 6.5.7 allows a Block Read byte count of 0, but the atomic (polling) path rejects it as -EPROTO. Worse, it returns without a NACK+STOP: the next receive cycle has already started, so the target keeps holding SDA and the bus stays stuck until a power cycle for this i2c controller. Reading I2DR to obtain the count likewise arms the next byte on the count > I2C_SMBUS_BLOCK_MAX path, which also returned -EPROTO directly and left the bus held. Handle both: NACK the in-flight dummy byte (TXAK) and extend msgs->len so the existing last-byte handling emits STOP; the dummy byte is discarded. A count of 0 is a valid empty block read; a count above I2C_SMBUS_BLOCK_MAX is still reported as -EPROTO, but only after the bus has been released. The interrupt-driven path has the same flaw from a later commit and is fixed separately, as it carries a different Fixes: tag and stable range.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72147", "url": "https://ubuntu.com/security/CVE-2026-72147", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: dw-edma-pcie: Reject devices without driver data dw_edma_pcie_probe() treats the PCI device ID driver_data as the template for the controller layout and copies it unconditionally. A device bound dynamically via sysfs can match the driver without that data, which leads to a NULL pointer dereference. Reject such matches before enabling the device.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72254", "url": "https://ubuntu.com/security/CVE-2026-72254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_fib: reject fib expression on the netdev egress hook A fib expression in a netdev egress base chain dereferences nft_in(pkt), NULL on the transmit path, causing a NULL pointer dereference at eval. nft_fib_validate() masks the hook with NF_INET_* values, but netdev hook numbers are a separate enum that aliases them (NF_NETDEV_EGRESS == NF_INET_LOCAL_IN), so an egress chain passes validation and then faults. Add nft_fib_netdev_validate() that limits each result/flag to the netdev hook where the device it reads exists: the input-device cases (OIF, OIFNAME, ADDRTYPE with F_IIF) to ingress, the output-device case (ADDRTYPE with F_OIF) to egress, ADDRTYPE with no device flag to both. Also restrict nft_fib_validate() to NFPROTO_IPV4/IPV6/INET so its NF_INET_* masks are not applied to another family's hooks.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72253", "url": "https://ubuntu.com/security/CVE-2026-72253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack_sip: validate skb_dst() before accessing it tc ingress and openvswitch do not guarantee routing information to be available. These subsystems use the conntrack helper infrastructure, and the SIP helper relies on the skb_dst() to be present if sip_external_media is set to 1 (which is disabled by default as a module parameter). This effectively disables the sip_external_media toggle for these subsystems without resulting in a crash.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72260", "url": "https://ubuntu.com/security/CVE-2026-72260", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: mediatek: mt8192: Check runtime resume during probe The MT8192 AFE probe enables runtime PM temporarily while reinitializing the regmap cache from hardware, but it uses pm_runtime_get_sync() without checking the return value. If runtime resume fails, probe keeps going without the device necessarily being accessible, and pm_runtime_get_sync() may leave the PM usage count incremented. The regmap_reinit_cache() failure path also returns before dropping the temporary PM reference and before clearing pm_runtime_bypass_reg_ctl. Use pm_runtime_resume_and_get() so resume failures do not leak a usage count, and clear the temporary bypass flag after dropping the probe PM reference on all regmap_reinit_cache() outcomes.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72305", "url": "https://ubuntu.com/security/CVE-2026-72305", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: VDUSE: avoid leaking information to userspace The bounceing is not necessarily page aligned, so current VDUSE can leak kernel information through mapping bounce pages to userspace. Allocate bounce pages with __GFP_ZERO to avoid leaking information to userspace.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72299", "url": "https://ubuntu.com/security/CVE-2026-72299", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: restrict socket queue dumps in enqueue tracepoints tipc_sk_enqueue() runs with sk->sk_lock.slock held while the socket is owned by user context. The spinlock protects the backlog queue in this path, but it does not serialize against the socket owner consuming or purging sk_receive_queue. KASAN reported: CPU: 14 UID: 0 PID: 1050 Comm: tipc3 Not tainted 7.1.0-rc6+ #126 PREEMPT(lazy) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Call Trace: dump_stack_lvl+0x76/0xa0 lib/dump_stack.c:123 print_report+0xce/0x5b0 mm/kasan/report.c:482 kasan_report+0xc6/0x100 mm/kasan/report.c:597 __asan_report_load4_noabort+0x14/0x30 mm/kasan/report_generic.c:380 tipc_skb_dump+0x1327/0x16f0 net/tipc/trace.c:73 tipc_list_dump+0x208/0x2e0 net/tipc/trace.c:187 tipc_sk_dump+0xaf6/0xd60 net/tipc/socket.c:3996 trace_event_raw_event_tipc_sk_class+0x312/0x5a0 net/tipc/trace.h:188 tipc_sk_rcv+0xb1d/0x1d50 net/tipc/socket.c:2497 tipc_node_xmit+0x1c3/0x1440 net/tipc/node.c:1689 __tipc_sendmsg+0x97a/0x1440 net/tipc/socket.c:1512 tipc_sendmsg+0x52/0x80 net/tipc/socket.c:1400 sock_sendmsg+0x2f6/0x3e0 net/socket.c:825 splice_to_socket+0x7f9/0x1010 fs/splice.c:884 do_splice+0xe21/0x2330 fs/splice.c:936 __do_splice+0x153/0x260 fs/splice.c:1431 __x64_sys_splice+0x150/0x230 fs/splice.c:1616 x64_sys_call+0xeb5/0x2790 arch/x86/entry/syscall_64.c:41 do_syscall_64+0xf3/0x620 arch/x86/entry/syscall_64.c:63 entry_SYSCALL_64_after_hwframe+0x76/0x7e arch/x86/entry/entry_64.S:130 RIP: 0033:0x71624e8aafe2 Code: 08 0f 85 71 3a ff ff 49 89 fb 48 89 f0 48 89 d7 48 89 ce 4c 89 c2 4d 89 ca 4c 8b 44 24 08 4c 8b 4c 24 10 4c 89 5c 24 08 0f 05 66 2e 0f 1f 84 00 00 00 00 00 66 2e 0f 1f 84 00 00 00 00 00 66 RSP: 002b:0000716157ffed68 EFLAGS: 00000246 ORIG_RAX: 0000000000000113 RAX: ffffffffffffffda RBX: 0000716157fff6c0 RCX: 000071624e8aafe2 RDX: 000000000000005f RSI: 0000000000000000 RDI: 0000000000000066 RBP: 0000716157ffed90 R08: 0000000000008000 R09: 0000000000000001 R10: 0000000000000000 R11: 0000000000000246 R12: ffffffffffffff00 R13: 0000000000000021 R14: 0000000000000000 R15: 00007fff89799c40 The TIPC_DUMP_ALL tracepoints in tipc_sk_enqueue() also dump sk_receive_queue and can therefore dereference skbs that the socket owner has already dequeued or freed. Restrict these dumps to TIPC_DUMP_SK_BKLGQ, which matches the queue protected by the held spinlock. Keep the change limited to the enqueue path, where the unsafe queue dump is reachable while the socket is owned by user context.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74436", "url": "https://ubuntu.com/security/CVE-2026-74436", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: serialize kernel accept preallocation with socket teardown rxrpc_kernel_charge_accept() reads rx->backlog without any socket/backlog synchronization and passes that raw pointer into rxrpc_service_prealloc_one(). A concurrent rxrpc_discard_prealloc() sets rx->backlog = NULL and frees the backlog rings, so a kernel preallocation worker can keep using a freed struct rxrpc_backlog while updating *_backlog_head/tail and array slots. Serialize the state check and backlog lookup with the socket lock, and reject kernel preallocation once teardown has disabled listening or discarded the service backlog.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64205", "url": "https://ubuntu.com/security/CVE-2026-64205", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: i801: fix hardware state machine corruption in error path A severe livelock and subsequent Hung Task panic were observed in the i2c-i801 driver during concurrent Fuzzing. The crash is caused by an unconditional hardware register cleanup in the error handling path of i801_access(). When i801_check_pre() fails (e.g., returning -EBUSY because the SMBus controller is actively used by BIOS/ACPI), the kernel does not actually acquire the hardware ownership. However, the code jumps to the 'out' label and executes: iowrite8(SMBHSTSTS_INUSE_STS | STATUS_FLAGS, SMBHSTSTS(priv)); This forcefully clears the INUSE_STS lock and resets the hardware status flags without owning the controller. Doing so interrupts ongoing BIOS/ACPI transactions and totally corrupts the SMBus hardware state machine. Consequently, all subsequent i801_access() calls fail at the pre-check stage, triggering an endless stream of \"SMBus is busy, can't use it!\" error logs. Over a slow serial console, this printk flood monopolizes the CPU (Console Livelock), starving other processes trying to acquire the mmap_lock down_read semaphore, ultimately triggering the hung task watchdog. Fix this by moving the 'out' label below the hardware register cleanup. If i801_check_pre() fails, we safely bypass the iowrite8() and only release the software locks (pm_runtime and mutex), strictly adhering to the rule of not releasing resources that were never acquired.", "cve_priority": "medium", "cve_public_date": "2026-07-20 17:18:00 UTC" }, { "cve": "CVE-2026-68096", "url": "https://ubuntu.com/security/CVE-2026-68096", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: audit: fix recursive locking deadlock in audit_dupe_exe() A deadlock occurs in the audit subsystem when duplicating executable-related rules. When a file is moved (e.g., via do_renameat2()), the VFS layer locks the parent directory (I_MUTEX_PARENT), which synchronously triggers an fsnotify_move event. If an existing executable audit rule matches the file being moved, the audit subsystem catches this event and calls audit_dupe_exe() to duplicate the watch and update the rule. Then, audit_alloc_mark() would call kern_path_parent() to resolve the path, leading to a blind attempt to acquire the exact same I_MUTEX_PARENT lock already held by the task, resulting in the following recursive locking deadlock: ============================================ WARNING: possible recursive locking detected 6.12.0-55.27.1.el10_0.x86_64+debug #1 Not tainted -------------------------------------------- mv/5099 is trying to acquire lock: ffff888132845358 (&inode->i_sb->s_type->i_mutex_dir_key/1){+.+.}-{3:3}, at: __kern_path_locked+0x10a/0x2f0 but task is already holding lock: ffff888132846b58 (&inode->i_sb->s_type->i_mutex_dir_key/1){+.+.}-{3:3}, at: lock_two_directories+0x13f/0x2b0 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&inode->i_sb->s_type->i_mutex_dir_key/1); lock(&inode->i_sb->s_type->i_mutex_dir_key/1); *** DEADLOCK *** May be due to missing lock nesting notation 6 locks held by mv/5099: #0: ffff888112a9c440 (sb_writers#13) at: do_renameat2+0x34c/0xbc0 #1: ffff888112a9c790 (&type->s_vfs_rename_key#3) at: do_renameat2+0x415/0xbc0 #2: ffff888132846b58 (&inode->i_sb->s_type->i_mutex_dir_key/1) at: lock_two_directories+0x13f/0x2b0 #3: ffff888132845358 (&inode->i_sb->s_type->i_mutex_dir_key/5) at: lock_two_directories+0x175/0x2b0 #4: ffffffffb3a1fb10 (&fsnotify_mark_srcu) at: fsnotify+0x454/0x28a0 #5: ffffffffaf886230 (audit_filter_mutex) at: audit_update_watch+0x36/0x11e0 stack backtrace: Call Trace: dump_stack_lvl+0x6f/0xb0 print_deadlock_bug.cold+0xbd/0xca validate_chain+0x83a/0xf00 __lock_acquire+0xcac/0x1d20 lock_acquire.part.0+0x11b/0x360 down_write_nested+0x9f/0x230 __kern_path_locked+0x10a/0x2f0 kern_path_locked+0x26/0x40 audit_alloc_mark+0xfb/0x4f0 audit_dupe_exe+0x6c/0xe0 audit_dupe_rule+0x6c2/0xc00 audit_update_watch+0x4cc/0x11e0 audit_watch_handle_event+0x12c/0x1b0 send_to_group+0x5d0/0x8b0 fsnotify+0x615/0x28a0 fsnotify_move+0x1d8/0x630 vfs_rename+0xdcd/0x1df0 do_renameat2+0x9d4/0xbc0 __x64_sys_renameat+0x192/0x260 do_syscall_64+0x92/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f0491fe8c4e Code: 0f 1f 40 00 48 8b 15 c1 e1 16 00 f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa 49 89 ca b8 08 01 00 00 0f 05 <48> 3d 00 f0 ff ff 77 0a c3 66 0f 1f 84 00 00 00 00 00 48 8b 15 89 RSP: 002b:00007ffc7210bf38 EFLAGS: 00000246 ORIG_RAX: 0000000000000108 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f0491fe8c4e RDX: 0000000000000003 RSI: 00007ffc7210e6c8 RDI: 00000000ffffff9c RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000001 R10: 00005575eb2dae2a R11: 0000000000000246 R12: 00005575eb2dae2a R13: 00007ffc7210e6c8 R14: 0000000000000003 R15: 00000000ffffff9c The aforementioned deadlock can be consistently reproduced by running the script below: audit-dupe-exe-deadlock.sh -------------------------- #!/bin/bash auditctl -D mkdir -p /tmp/foo touch /tmp/file auditctl -a always,exit -F exe=/tmp/file -F path=/tmp/file -S all -k dr mv /tmp/file /tmp/foo/file rm -Rf /tmp/foo This patch fixes the issue by introducing struct audit_watch_ctx to pass the fsnotify event context down to audit_alloc_mark(). By utilizing the already-resolved directory inode provided by the event, we bypass the kern_path_parent() path resol ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-64280", "url": "https://ubuntu.com/security/CVE-2026-64280", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fpga: dfl-afu: validate DMA mapping length in afu_dma_map_region() afu_ioctl_dma_map() accepts a 64-bit length from userspace via DFL_FPGA_PORT_DMA_MAP ioctl without an upper bound check. The value is passed to afu_dma_pin_pages() where npages is derived as length >> PAGE_SHIFT and passed to pin_user_pages_fast() which takes int nr_pages, causing implicit truncation if length is very large. Validate map.length at the ioctl entry point before calling afu_dma_map_region(), rejecting values whose page count exceeds INT_MAX.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-68147", "url": "https://ubuntu.com/security/CVE-2026-68147", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fscrypt: Avoid dynamic allocation in fscrypt_get_devices() When a blk_crypto_key starts being used or is evicted, fs/crypto/ calls fscrypt_get_devices() to get the filesystem's list of block devices, then iterates over them and calls blk_crypto_config_supported(), blk_crypto_start_using_key(), or blk_crypto_evict_key() on each one. Currently, the block device pointers are placed in a dynamically allocated array. This dynamic allocation is problematic because: - It can fail, especially at the fscrypt_destroy_inline_crypt_key() call site when it's invoked for inode eviction under direct reclaim. - fscrypt_destroy_inline_crypt_key() doesn't handle the failure. It just zeroizes and frees the blk_crypto_key without calling blk_crypto_evict_key(). That causes a use-after-free. For now, let's fix this in the straightforward and easily-backportable way by switching to an on-stack array. Currently the fscrypt multi-device functionality is used only by f2fs, which has a hardcoded limit of 8 block devices. An on-stack array works fine for that. (Of course, this solution won't scale up to large number of block devices. For that we'd need a different solution, like moving the block device iteration into the filesystem. Or in the case of btrfs, which will only support blk-crypto-fallback, we should make it just call blk-crypto-fallback directly, so the block devices won't be needed.)", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68123", "url": "https://ubuntu.com/security/CVE-2026-68123", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: openvswitch: fix GSO userspace truncation underflow OVS_ACTION_ATTR_TRUNC currently stores a delta from the original skb length in OVS_CB(skb)->cutlen. When a later userspace action segments a GSO skb, queue_gso_packets() reuses that delta for each smaller segment. A segment can then reach queue_userspace_packet() with cutlen greater than skb->len, underflowing the length passed to skb_zerocopy(). Store the maximum preserved length instead and bound each consumer against the current skb length. Use U32_MAX as the no-truncation sentinel so the value remains valid if skb geometry changes before a consumer handles it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68097", "url": "https://ubuntu.com/security/CVE-2026-68097", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate ACE size against SID sub-authorities set_ntacl_dacl() validates sid.num_subauth before copying an ACE, but does not verify that the declared ACE size contains all sub-authorities described by that field. An undersized ACE can therefore be copied and later make the POSIX ACL deduplication walk inspect data beyond the copied ACE boundary. The existing initial bound check is also too small. It only ensures that the ACE size field is accessible before set_ntacl_dacl() reads sid.num_subauth farther into the input buffer. Require enough input for the fixed SID header before accessing num_subauth, reject ACEs smaller than that header, and skip ACEs whose declared size cannot contain the complete SID. This makes the validation consistent with the other ACE walk paths.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68098", "url": "https://ubuntu.com/security/CVE-2026-68098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: bound DACL dedup walk to copied ACEs set_ntacl_dacl() can stop copying ACEs before consuming the full input DACL when size accounting overflows. When that happens, num_aces reflects only the ACEs that were actually copied into the output DACL, but set_posix_acl_entries_dacl() still receives nt_num_aces and uses it to walk the existing ACE array during dedup. That makes the dedup walk scan past the copied ACE array and inspect buffer tail that does not contain valid ACEs. Split the two meanings currently carried by the NT ACE count. Pass the number of copied NT ACEs to bound the dedup walk, and preserve the original \"input DACL had NT ACEs\" state separately for the Everyone/default ACL fallback. This keeps the dedup walk aligned with the ACEs that are actually present in the rebuilt DACL.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68099", "url": "https://ubuntu.com/security/CVE-2026-68099", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: restore DACL size on check_add_overflow() to avoid malformed ACL check_add_overflow() unconditionally writes the truncated sum into *d even on overflow, per its contract in include/linux/overflow.h. The four check_add_overflow() guards in set_posix_acl_entries_dacl() and set_ntacl_dacl() break out of the ACE-building loops on overflow, but the truncated *size is then consumed downstream at the end of set_ntacl_dacl(): pndacl->size = cpu_to_le16(le16_to_cpu(pndacl->size) + size); This produces an on-wire NT ACL whose pndacl->size under-reports the bytes actually written by the preceding fill_ace_for_sid()/memcpy() calls, yielding a malformed ACL that can trigger out-of-bounds reads when re-parsed by clients or ksmbd itself. Restore *size to its pre-addition value on each overflow branch (via `*size -= ace_sz` / `size -= nt_ace_size`) so that after the break, *size once again holds the cumulative size of the successfully-written ACEs. The committed ACL is then truncated-but-self-consistent rather than malformed. The ksmbd DACL builders are the only check_add_overflow() sites found where an overflow path breaks out of a loop and the destination value is consumed afterward. The other nearby break-style cases either return -EINVAL on overflow (transport_ipc.c) or break without consuming the overflowed destination value afterward (buildid.c).", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68100", "url": "https://ubuntu.com/security/CVE-2026-68100", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate num_subauth when copying ACE in set_ntacl_dacl set_ntacl_dacl() copies each ACE from the attacker-controlled stored security descriptor verbatim into the response DACL without checking sid.num_subauth. The ACE bytes (including an unchecked num_subauth) originate from an authenticated SMB2_SET_INFO(SecInfo=DACL) that is stored raw via ksmbd_vfs_set_sd_xattr(); parse_dacl() rejects a bad ACE with `break` rather than an error, so parse_sec_desc() still returns success and the malformed SD reaches the xattr intact. On a subsequent SMB2_QUERY_INFO(SecInfo=DACL) for an inode carrying a POSIX access ACL, build_sec_desc() -> set_ntacl_dacl() -> set_posix_acl_entries_dacl() walks the copied ACEs and reads ntace->sid.sub_auth[ntace->sid.num_subauth - 1] with num_subauth taken straight from the stored SD. Since sub_auth[] is fixed at SID_MAX_SUB_AUTHORITIES (15), a crafted num_subauth (e.g. 255) drives an out-of-bounds heap read of ~1 KB with an offset fully controlled by an authenticated client. The sibling functions already gate this field: parse_dacl() -- num_subauth == 0 || > SID_MAX_SUB_AUTHORITIES parse_sid() -- num_subauth > SID_MAX_SUB_AUTHORITIES smb_copy_sid() -- min_t(u8, num_subauth, SID_MAX_SUB_AUTHORITIES) set_ntacl_dacl() is the lone inconsistent path that omits the check. Add the same num_subauth validation in set_ntacl_dacl() before copying the ACE, matching the gate already enforced by parse_dacl().", "cve_priority": "high", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68104", "url": "https://ubuntu.com/security/CVE-2026-68104", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: invoke pm_genpd_remove() before freeing genpd Call pm_genpd_remove() to unregister from global list prior to releasing acp_genpd memory, and clear the pointer after free. (cherry picked from commit cd8650d7a91ee8b768e202354672553faa5cc1f2)", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68106", "url": "https://ubuntu.com/security/CVE-2026-68106", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix division by zero with invalid uvd dimensions When width or height is less than 16, width_in_mb or height_in_mb becomes 0, leading to fs_in_mb being 0. This causes a division by zero when calculating num_dpb_buffer in H264 and H264 Perf decode paths. Add validation to reject frames with width < 16 or height < 16 before performing any calculations that depend on these values. V2: Format change - move up all vaiable definitions. V3: Use warn_once to avoid spam. (cherry picked from commit 3e41d26c70b0a459d041cc19482a226c4b7423cb)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68429", "url": "https://ubuntu.com/security/CVE-2026-68429", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/dp_mst: Handle torn-down topology gracefully in drm_dp_mst_topology_queue_probe() A hotplug or link-loss event can tear down the MST topology (setting mgr->mst_state = false and mgr->mst_primary = NULL) concurrently with a caller invoking drm_dp_mst_topology_queue_probe(). Since the check is already performed under mgr->lock, the condition is not a programming error but a valid race -- the topology was valid when the caller decided to call this function, but was torn down before the lock was acquired. Replace the drm_WARN_ON() with a graceful early return. This eliminates spurious kernel warnings and the resulting compositor crashes observed when connecting/disconnecting DP MST monitors, while keeping the correct behavior of doing nothing when MST is not active. A drm_dbg_mst() trace is added so the skipped probe remains observable under MST debug logging. The existing WARN_ON(mgr->mst_primary) in drm_dp_mst_topology_mgr_set_mst() already catches the case where the topology is initialized twice, so no diagnostic coverage is lost.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68107", "url": "https://ubuntu.com/security/CVE-2026-68107", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/vcn4: avoid rereading IB param length Reuse the parameter length returned by vcn_v4_0_enc_find_ib_param() instead of rereading it from the IB. This avoids a potential TOCTOU issue if the IB contents change between reads. (cherry picked from commit dbb02b4755f8c1f3773263f2d779872c1c0c073a)", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68108", "url": "https://ubuntu.com/security/CVE-2026-68108", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/vce: fix integer overflow in image size Fix a security vulnerability where malicious VCE command streams with oversized dimensions (e.g. 65536×65536) cause 32-bit integer overflow, wrapping the calculated buffer size to 0. This bypasses validation and allows GPU firmware to perform out-of-bound memory access. The fix uses 64-bit arithmetic to detect overflow and rejects invalid dimensions before they reach the hardware. V2: remove redundant check V3: modify max height value V4: remove size64 (cherry picked from commit cbe408dba581755ad1279a487ec786d8927d778d)", "cve_priority": "high", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68110", "url": "https://ubuntu.com/security/CVE-2026-68110", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma4.4.2: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit fa4f86a148271e325e95287630a3a15a9cd35fdc)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68111", "url": "https://ubuntu.com/security/CVE-2026-68111", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx9: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit b71604f8685b0eba07866f4e8dc30f93e1931054)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68112", "url": "https://ubuntu.com/security/CVE-2026-68112", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx9.4.3: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit 5676593d08998d7a6d9e2d51d6b54b3820e3755c)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68430", "url": "https://ubuntu.com/security/CVE-2026-68430", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx8: drop unecessary BUG_ON() There's no need to crash the kernel for this case. (cherry picked from commit 4d7c25208ca612b754f3bf39e9f16e725b828891)", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68246", "url": "https://ubuntu.com/security/CVE-2026-68246", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx11: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit daa62107452d2451787c4248ca38fa2d1a0cbefd)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68115", "url": "https://ubuntu.com/security/CVE-2026-68115", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx10: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit ac6f00beb658239bced4aaed9efbb04a35348d48)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68116", "url": "https://ubuntu.com/security/CVE-2026-68116", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: mdb: Fix source list corruption on a failed replace When replacing the source list of an MDB remote entry, all existing sources are first marked for deletion and vxlan_mdb_remote_srcs_add() is then called to add the new source list. Sources present in the new list have their deletion mark cleared, and any sources left marked afterwards are removed. If vxlan_mdb_remote_srcs_add() fails partway through, its error path deletes all entries on the remote's source list. That rollback is only correct for its other caller, vxlan_mdb_remote_add(), where the remote was just allocated and the list contains solely entries added during the call. On the replace path the list also holds pre-existing sources, so a failed replace tears them down together with their (S, G) forwarding entries instead of leaving the entry unchanged. This is reachable from an existing (*, G) remote. An EXCLUDE filter that loses sources starts forwarding traffic that should be blocked, while an INCLUDE filter that loses sources drops traffic that should be forwarded. Mark entries created during the current pass with a new VXLAN_SGRP_F_NEW flag. On failure, delete only those entries and clear the deletion mark on the pre-existing ones, so a failed replace leaves the source list untouched. Retain the flag until the whole operation succeeds and then clear it. Also stop vxlan_mdb_remote_src_add() from deleting a pre-existing entry it only looked up when adding that entry's forwarding entry fails.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68117", "url": "https://ubuntu.com/security/CVE-2026-68117", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: clear sock->sk on the failed-insert path in tipc_sk_create() When tipc_sk_create() fails to insert the new socket (tipc_sk_insert() returns non-zero), its error path frees the sk with sk_free() but leaves sock->sk pointing at the freed object: \tif (tipc_sk_insert(tsk)) { \t\tsk_free(sk); \t\tpr_warn(\"Socket create failed; port number exhausted\\n\"); \t\treturn -EINVAL; \t} This is harmless for plain socket(): the syscall layer clears sock->ops before releasing, so tipc_release() is never called. It is not harmless on the accept() path. tipc_accept() creates the pre-allocated child socket with tipc_sk_create(net, new_sock, 0, kern); on failure it leaves new_sock->sk dangling and new_sock->ops non-NULL, and do_accept() then fput()s the new file, so __sock_release() -> tipc_release() runs lock_sock(new_sock->sk) on the freed sk -- a use-after-free write of the sk_lock spinlock. tipc_release() already guards this exact \"failed accept() releases a pre-allocated child\" case with \"if (sk == NULL) return 0;\", but the guard is bypassed because tipc_sk_create() left sock->sk non-NULL (dangling) rather than NULL. Clear sock->sk on the failed-insert path so the existing tipc_release() NULL check fires and the use-after-free is avoided. The tipc_sk_insert() failure is reached when the per-netns socket rhashtable hits its max_size (tsk_rht_params.max_size = 1048576, ~2M elements) -- i.e. once a netns holds ~2M TIPC sockets every insert returns -E2BIG. BUG: KASAN: slab-use-after-free in lock_sock_nested (net/core/sock.c:3839) Write of size 8 at addr ffff8880047cdc38 by task init/1 lock_sock_nested (net/core/sock.c:3839) tipc_release (net/tipc/socket.c:638) __sock_release (net/socket.c:710) sock_close (net/socket.c:1501) __fput (fs/file_table.c:512) Allocated by task 1: sk_alloc (net/core/sock.c:2308) tipc_sk_create (net/tipc/socket.c:487) tipc_accept (net/tipc/socket.c:2744) do_accept (net/socket.c:2034) Freed by task 1: __sk_destruct (net/core/sock.c:2391) tipc_sk_create (net/tipc/socket.c:504) tipc_accept (net/tipc/socket.c:2744) do_accept (net/socket.c:2034)", "cve_priority": "high", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68121", "url": "https://ubuntu.com/security/CVE-2026-68121", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pppoe: reload header pointer after dev_hard_header() pppoe_sendmsg() saves a pointer to the PPPoE header before calling dev_hard_header(). Device header callbacks are allowed to reallocate the skb head, invalidating pointers into it. This can happen when a send is blocked in copy_from_user() while the first non-Ethernet port is added to an empty team device. The team's delegated GRE header callback then expands the skb head. PPPoE subsequently writes six bytes through the stale pointer into the freed head. Reload the PPPoE header through the skb's network-header offset after device header creation. pskb_expand_head() updates that offset when it relocates the head.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68124", "url": "https://ubuntu.com/security/CVE-2026-68124", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mctp: serial: handle zero-length frames to prevent rx buffer overflow The MCTP serial receive state machine reads a frame length byte in mctp_serial_push_header() case 2 and validates it upper-bound-only: \tif (c > MCTP_SERIAL_FRAME_MTU) { \t\tdev->rxstate = STATE_ERR; \t} else { \t\tdev->rxlen = c; \t\tdev->rxpos = 0; \t\tdev->rxstate = STATE_DATA; \t\t... \t} A length of zero passes this check, so rxlen is set to 0 and the state machine advances to STATE_DATA. In mctp_serial_push() STATE_DATA, the incoming byte is stored and rxpos incremented before the terminator is \tdev->rxbuf[dev->rxpos] = c; \tdev->rxpos++; \tdev->rxstate = STATE_DATA; \tif (dev->rxpos == dev->rxlen) { \t\tdev->rxpos = 0; \t\tdev->rxstate = STATE_TRAILER; \t} With rxlen == 0 the \"rxpos == rxlen\" terminator can never fire (rxpos is already 1 on the first data byte), so subsequent bytes are written past the end of the fixed 74-byte rxbuf, which is the last member of the netdev private area. Every following data byte is an attacker-controlled 1-byte out-of-bounds heap write, and the overflow continues until a frame (0x7e) or escape byte resets the parser -- effectively unbounded. Reaching this requires CAP_NET_ADMIN to attach the N_MCTP line discipline and bring the resulting mctpserialN netdev up, after which the bytes arrive via the tty receive path. Route a zero-length frame straight to STATE_TRAILER instead of STATE_DATA. The trailer/framing bytes are still consumed, and the frame resolves to a zero-length skb that the MCTP core rejects; the parser never enters STATE_DATA with rxlen == 0, so the out-of-bounds write can no longer occur. KASAN, on a frame of 0x7e 0x01 0x00 followed by data bytes (before this change): UBSAN: array-index-out-of-bounds in drivers/net/mctp/mctp-serial.c:370 index 74 is out of range for type 'u8 [74]' BUG: KASAN: slab-out-of-bounds in mctp_serial_tty_receive_buf Write of size 1 at addr ... by task kworker/u16:0 mctp_serial_tty_receive_buf tty_ldisc_receive_buf flush_to_ldisc Allocated by task 152: alloc_netdev_mqs mctp_serial_open v2: route zero-length frames to STATE_TRAILER instead of STATE_ERR so the trailer/framing bytes are still consumed (Jeremy Kerr). Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68125", "url": "https://ubuntu.com/security/CVE-2026-68125", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mac802154: llsec: reject frames shorter than the authentication tag llsec_do_decrypt_auth() computes the associated-data length for the AEAD request as \tassoclen += datalen - authlen; where datalen is the number of bytes after the MAC header and authlen (4, 8 or 16) is the length of the authentication tag. Nothing verifies that the frame actually carries at least authlen payload bytes. A secured frame whose payload is shorter than the tag makes datalen - authlen negative; assoclen is then passed to aead_request_set_ad() as an unsigned value close to 4 GiB, so crypto_aead_decrypt() walks far off the end of the scatterlist that only spans the real frame. The frame is fully attacker-controlled and reaches this path from any IEEE 802.15.4 peer in radio range. Reject frames whose payload is shorter than the authentication tag before the subtraction. Dynamically reproduced on a KASAN kernel as a general-protection-fault in the AEAD scatterwalk, and the fix confirmed.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68126", "url": "https://ubuntu.com/security/CVE-2026-68126", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mac802154: hold an interface reference across the scan worker mac802154_scan_worker() captures the scanning sub-interface under RCU and then keeps dereferencing sdata->dev after rcu_read_unlock() and outside the rtnl -- in the failure traces, in mac802154_transmit_beacon_req() (skb->dev = sdata->dev), and in the end_scan cleanup. Nothing keeps that netdev alive across the worker iteration. A concurrent DEL_INTERFACE or PHY removal can unregister the interface once the worker drops the rtnl between its two drv_set_channel() sections. unregister_netdevice() frees the netdev asynchronously from netdev_run_todo() with the rtnl already dropped, so neither holding the rtnl nor the per-PHY IEEE802154_IS_SCANNING flag prevents a stale worker iteration from dereferencing the freed netdev -- a KASAN slab-use-after-free, reachable by racing TRIGGER_SCAN against DEL_INTERFACE (both CAP_NET_ADMIN). Pin the netdev with netdev_hold() while the RCU read lock is still held, and release it at every worker exit.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68127", "url": "https://ubuntu.com/security/CVE-2026-68127", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ila: reload IPv6 header after pskb_may_pull in checksum adjust ila_csum_adjust_transport() caches ip6h = ipv6_hdr(skb) before calling pskb_may_pull(). On a non-linear skb whose transport header sits in a page fragment, pskb_may_pull() can call __pskb_pull_tail() / pskb_expand_head() and free the old skb head, leaving ip6h dangling; the following get_csum_diff(ip6h, p) then reads freed memory. ila_update_ipv6_locator() uses ip6h (and the iaddr derived from it) again after the csum-adjust call and additionally writes the new locator through that pointer. Impact: a remote IPv6 packet routed through a configured ILA csum-adjust-transport route or receive-side mapping triggers a slab-use-after-free in ila_update_ipv6_locator() (KASAN). The route or mapping requires CAP_NET_ADMIN to configure, but trigger packets are unauthenticated once it exists. Reload ip6h after each pskb_may_pull() in ila_csum_adjust_transport() before the csum-diff read. In ila_update_ipv6_locator() only the ILA_CSUM_ADJUST_TRANSPORT case pulls the skb, so reload ip6h and iaddr in that case alone before the destination-address write; the neutral-map modes never pull and keep their cached pointers.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68130", "url": "https://ubuntu.com/security/CVE-2026-68130", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: defer destroy_previous_session() until after NTLM authentication In ntlm_authenticate(), destroy_previous_session() is called using a user pointer resolved from the client-supplied NTLM blob username field before the NTLMv2 response is validated. An authenticated attacker can set the NTLM blob username to match a victim account and set PreviousSessionId to the victim's session ID; destroy_previous_session() destroys the victim's session while ksmbd_decode_ntlmssp_auth_blob() subsequently rejects the request with -EPERM. Move destroy_previous_session() and the prev_id assignment to after ksmbd_decode_ntlmssp_auth_blob() returns success and use sess->user rather than the pre-authentication lookup result. This matches the ordering already used by krb5_authenticate(), where destroy_previous_session() is called only after ksmbd_krb5_authenticate() returns success.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68131", "url": "https://ubuntu.com/security/CVE-2026-68131", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rbd: Reset positive result codes to zero in object map update path In a reply message to an RBD request, a positive result code indicates a data payload, which is not allowed for writes. While rbd_osd_req_callback() already resets a positive result code for writes to zero, rbd_object_map_callback() does not. This allows a corrupted reply to an object map update to trigger the rbd_assert(*result < 0) in __rbd_obj_handle_request(). This happens, because rbd_object_map_callback() calls rbd_obj_handle_request() -> __rbd_obj_handle_request() and passes this positive result code. From __rbd_obj_handle_request(), rbd_obj_advance_write() is called, which leaves the positive result code unchanged and returns true. Therefore, the if(done && *result) branch is executed in __rbd_obj_handle_request() and the assertion triggers. This patch fixes the issue by adjusting the logic in the rbd_object_map_callback() path. A positive result code for an object map update is now reset to zero (similar to rbd_osd_req_callback()), and the message is subsequently handled the same way as if the result code was zero from the beginning. Additionally, a WARN_ON_ONCE() is added for this case.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68135", "url": "https://ubuntu.com/security/CVE-2026-68135", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hip04: fix RX buffer leak on build_skb failure When build_skb() fails in hip04_rx_poll(), the driver jumps to the refill path without releasing the current RX buffer and its DMA mapping. Installing a replacement buffer then overwrites the slot references and leaks both resources. Keep the current slot intact and return budget so NAPI retries the same buffer. Also free a newly allocated RX fragment when dma_map_single() fails. This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68137", "url": "https://ubuntu.com/security/CVE-2026-68137", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/x25: fix use-after-free in x25_kill_by_neigh() x25_kill_by_neigh() walks the global X.25 socket list looking for sockets attached to a terminating neighbour. x25_list_lock protects list membership while the lookup is in progress, but it does not pin a socket's lifetime after the lock is dropped. The function currently drops x25_list_lock before calling lock_sock(s). A concurrent close can run x25_release(), remove the same socket from x25_list, and drop the last socket reference in that window. The neighbour teardown path can then lock or inspect a freed struct sock/struct x25_sock. Take sock_hold(s) while x25_list_lock still proves that the list entry is live, then drop the temporary reference after the socket has been locked, rechecked, and released. Recheck x25_sk(s)->neighbour after lock_sock(), because another path may have disconnected the socket before this path acquired the socket lock. Restart the list walk after each disconnect because the list lock was dropped and the previous iterator state may no longer be valid. A QEMU/KASAN run against origin/master reproduced a slab-use-after-free in x25_kill_by_neigh().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68140", "url": "https://ubuntu.com/security/CVE-2026-68140", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/iucv: fix use-after-free of a severed iucv_path af_iucv queues not-yet-received message notifications on iucv->message_q, each holding a raw pointer to the connection's iucv_path. When the peer severs the connection, iucv_sever_path() frees that path with iucv_path_free() but leaves the notifications queued. A later recvmsg() drains message_q via iucv_process_message_q() and hands the stale path to message_receive() -- a use-after-free of the freed iucv_path. Drop the queued notifications when the path is severed; once the path is gone they can no longer be received. This also frees the notifications leaked when a socket is closed with messages still queued.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68141", "url": "https://ubuntu.com/security/CVE-2026-68141", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/af_iucv: fix NULL deref in afiucv_hs_callback_syn() afiucv_hs_callback_syn() allocates the child socket with GFP_ATOMIC. If the allocation fails, nsk is NULL. The connection-refused path is entered when the listen state check fails, the accept backlog is full, or nsk is NULL. The code unconditionally calls iucv_sock_kill(nsk) in that path. iucv_sock_kill() does not accept a NULL socket pointer and immediately dereferences sk via sock_flag(sk, SOCK_ZAPPED). When nsk is NULL, calling iucv_sock_kill(nsk) results in a NULL pointer dereference. Only call iucv_sock_kill() when a child socket was successfully allocated.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68142", "url": "https://ubuntu.com/security/CVE-2026-68142", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: geneve: require CAP_NET_ADMIN in the device netns for changelink A tunnel changelink() operates on at most two netns, dev_net(dev) and the sticky underlay netns geneve->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in geneve->net can rewrite a geneve device whose underlay lives in geneve->net. geneve_changelink() applies the new configuration against geneve->net: geneve_link_config() and the geneve_quiesce()/geneve_unquiesce() pair reopen the underlay sockets in that netns (geneve_sock_add() uses geneve->net), so the same reasoning as the tunnel changelink series applies here. Gate geneve_changelink() with rtnl_dev_link_net_capable(), at the top of the op before any attribute is parsed, matching ipgre_changelink() and the rest of the \"require CAP_NET_ADMIN in the device netns for changelink\" series. Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68143", "url": "https://ubuntu.com/security/CVE-2026-68143", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: slip: serialize receive against buffer reallocation sl_realloc_bufs() replaces rbuff and updates buffsize while holding sl->lock. slip_receive_buf() reads those fields and writes through rbuff without holding the lock. An MTU change can therefore race with receive processing. An MTU shrink can expose the new smaller rbuff with the old larger bound, causing an out-of-bounds write. A receive callback which already loaded the old rbuff can instead continue writing after that buffer has been freed. Serialize receive processing with sl_realloc_bufs() by holding sl->lock while consuming each receive batch.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68432", "url": "https://ubuntu.com/security/CVE-2026-68432", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: require CAP_NET_ADMIN in the device netns for changelink A tunnel changelink() operates on at most two netns, dev_net(dev) and the sticky underlay netns vxlan->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in vxlan->net can rewrite a vxlan device whose underlay lives in vxlan->net. vxlan_changelink() validates and applies the new configuration against vxlan->net (vxlan_config_validate(vxlan->net, ...)) and can reopen the underlay socket in that netns, so the same reasoning as the tunnel changelink series applies here. Gate vxlan_changelink() with rtnl_dev_link_net_capable(), at the top of the op before any attribute is parsed, matching ipgre_changelink() and the rest of the \"require CAP_NET_ADMIN in the device netns for changelink\" series. Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "low", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68144", "url": "https://ubuntu.com/security/CVE-2026-68144", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phonet: pep: fix use-after-free in pep_get_sb() pep_get_sb() doesn't consider that pskb_may_pull() might have relocated the skb data, and continue to access the older pointer, causing UAF. Reproduced under KASAN: BUG: KASAN: slab-use-after-free in pep_get_sb+0x234/0x3b0 Read of size 1 at addr ff11000105510f50 by task repro/157 pep_get_sb+0x234/0x3b0 pipe_handler_do_rcv+0x5f7/0xa10 pep_do_rcv+0x203/0x410 __sk_receive_skb+0x471/0x4a0 phonet_rcv+0x5b3/0x6c0 __netif_receive_skb+0xcc/0x1d0 Refetch the header with skb_header_pointer() after pskb_may_pull(), so the possibly stale pointer is no longer dereferenced. There are better ways to solve this, but, this is the less instrusive one.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68146", "url": "https://ubuntu.com/security/CVE-2026-68146", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ftrace: Add global mutex to serialize trace_parser access In ftrace, the trace_parser structure is allocated and initialized when a trace file is opened, and is subsequently used across write and release handlers to parse user input. The affected handler paths and their specific functions are: - Open paths: ftrace_regex_open(), ftrace_graph_open() - Write paths: ftrace_regex_write(), ftrace_graph_write() - Release paths: ftrace_regex_release(), ftrace_graph_release() If userspace opens a trace file descriptor and shares it across multiple threads, concurrent write calls will race on the parser's internal state, specifically the 'idx', 'cont', and 'buffer' fields, leading to corrupted input or undefined behavior. Fix this by adding a global mutex, parser_lock, to serialize all access to trace_parser across write and release paths, preventing concurrent corruption of parser state.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68148", "url": "https://ubuntu.com/security/CVE-2026-68148", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fscrypt: Add missing superblock check in find_or_insert_direct_key() The legacy 'fscrypt_direct_keys' table caches master keys that are used by v1 encryption policies that have FSCRYPT_POLICY_FLAG_DIRECT_KEY. It's just a global table for all filesystems (since the keys can be provided by the legacy process-subscribed keyrings mechanism, which makes it difficult to reuse super_block::s_master_keys). The entries in it ('struct fscrypt_direct_key') do contain a super_block pointer, though, for passing to fscrypt_destroy_inline_crypt_key() when the last inode that references the key is evicted. However, when finding the fscrypt_direct_key for an inode, we weren't actually comparing the super_block pointer. As a result, inodes with different super_blocks could point to the same fscrypt_direct_key. That could extend the lifetime of a fscrypt_direct_key beyond the super_block it points to, causing a use-after-free later. Fix this by creating distinct fscrypt_direct_key structs for distinct super_block structs. Note that this problem doesn't exist in the v2 policy equivalent (\"per-mode keys\"), since the data structures there are per super_block.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68149", "url": "https://ubuntu.com/security/CVE-2026-68149", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs: preserve ACL_DONT_CACHE state in forget_cached_acl() The ACL_DONT_CACHE state is meant to be a constant state for the inode for filesystems that want to opt out of posix acl caching. Commit facd61053cff1 (\"fuse: fixes after adapting to new posix acl api\") used this facility to opt out of posix acl caching for fuse inodes with fuse server that does not negotiate FUSE_POSIX_ACL (fc->posix_acl). The commit also takes care to gate the forget_all_cached_acls() call in fuse_set_acl() on fc->posix_acl because there is no need for it, but there are other placed in fuse code which call forget_all_cached_acls() unconditional to fc->posix_acl and those cause the loss of the ACL_DONT_CACHE state. This is not only a functional bug. Properly timed, a get_acl() from this fuse filesystem can return a stale cached value, as was observed in tests, because set_acl() does not invalidate the unintentional acl cache. We could fix this in fuse, but it actually makes no sense for the vfs helper forget_cached_acl() to invalidate the ACL_DONT_CACHE state, so let it not do that to fix fuse and future users of ACL_DONT_CACHE.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68151", "url": "https://ubuntu.com/security/CVE-2026-68151", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: binfmt_elf_fdpic: only honour the first PT_INTERP The program header scan handles PT_INTERP from a switch nested in the scan loop, so its break leaves the switch and not the loop. A binary carrying more than one PT_INTERP runs the case again and overwrites both interpreter_name and interpreter. The previous name allocation leaks and so does the previous interpreter reference, along with the write denial open_exec() took on it. The denial is never released, so the file stays unwritable for as long as the system runs. An unprivileged caller reaches this with a crafted binary and repeats it at will. binfmt_elf stops at the first PT_INTERP. Do the same here. The flaw dates back to the driver's introduction in the pre-git history tree introduced in v2.6.11 by 91808d6ebe39 (\"[PATCH] FRV: Add FDPIC ELF binary format driver\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68153", "url": "https://ubuntu.com/security/CVE-2026-68153", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: remove debugfs files before client teardown ceph_destroy_client() tears down the monitor client before removing the per-client debugfs files. A concurrent read of the monmap debugfs file can enter monmap_show() after ceph_monc_stop() has freed monc->monmap, triggering a use-after-free. Remove the debugfs files before stopping the OSD and monitor clients. debugfs_remove() drains active handlers and prevents new accesses, so the debugfs callbacks can no longer race the rest of client teardown.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68154", "url": "https://ubuntu.com/security/CVE-2026-68154", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: reject zero bucket types in crush_decode CRUSH bucket type 0 is reserved for devices. The mapper relies on that invariant and uses type 0 to identify leaf devices. If crush_decode() accepts a bucket with type 0, a malformed CRUSH map can make the mapper treat a negative bucket ID as a device and pass it to is_out(), which then indexes the OSD weight array with a negative value. Reject zero bucket types while decoding the CRUSH map so the invalid state never reaches the mapper.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68155", "url": "https://ubuntu.com/security/CVE-2026-68155", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: Reject monmaps advertising zero monitors A message of type CEPH_MSG_MON_MAP contains a monmap that is sent from a monitor to the client. This monmap contains information about the existing monitors in the cluster. Currently, a monmap indicating that there are zero monitors in the cluster is treated as valid. However, it is impossible to have zero monitors in the cluster and still receive a valid monmap from a monitor. Therefore, such a monmap must be corrupted and should be treated as invalid. Furthermore, a monmap with a monitor count of zero can subsequently crash the client when attempting to open a session with a monitor in __open_session(). This happens because the \"BUG_ON(monc->monmap->num_mon < 1)\" assertion in pick_new_mon() is triggered. This patch extends a check in ceph_monmap_decode() to also reject arriving mon_maps with num_mon == 0 rather than only with num_mon > CEPH_MAX_MON. [ idryomov: drop \"log output for unusual values of num_mon\" part ]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68156", "url": "https://ubuntu.com/security/CVE-2026-68156", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: refresh auth->authorizer_buf{,_len} after authorizer update ceph_x_create_authorizer() caches au->buf->vec.iov_base and au->buf->vec.iov_len in struct ceph_auth_handshake. These cached values are then used by the messenger connect code when sending the authorizer. ceph_x_update_authorizer() can rebuild the authorizer when a newer service ticket is available. If the rebuilt authorizer no longer fits in the existing buffer, ceph_x_build_authorizer() drops its reference to au->buf and allocates a new one. If this is the final reference, ceph_buffer_put() frees the old ceph_buffer and its vec.iov_base, but auth->authorizer_buf still points at that freed memory. A subsequent msgr1 reconnect can therefore queue the stale pointer and trigger a KASAN slab-use-after-free in _copy_from_iter() while tcp_sendmsg() copies the authorizer. Refresh auth->authorizer_buf and auth->authorizer_buf_len after a successful authorizer rebuild so the messenger sends the current buffer.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68157", "url": "https://ubuntu.com/security/CVE-2026-68157", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: guard missing CRUSH type name lookup Localized read selection can walk a parent bucket whose name exists in the CRUSH map while its type has no matching entry in type_names. get_immediate_parent() then dereferences a NULL type_cn and passes an invalid pointer into strcmp(), causing a null-ptr-deref. Skip such malformed parent buckets unless both the bucket name and type name metadata are present. This keeps malformed hierarchy data from crashing locality lookup and safely falls back to \"not local\". [ idryomov: add WARN_ON_ONCE ]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68158", "url": "https://ubuntu.com/security/CVE-2026-68158", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: Fix multiplication overflow in decode_new_up_state_weight() If a message of type CEPH_MSG_OSD_MAP contains a (maliciously) corrupted osdmap, out-of-bounds memory accesses may occur in decode_new_up_state_weight(). This happens because the bounds check for the new_state part is based on calculating its length depending on a len value read from the incoming message. This calculation may overflow leading to an incorrect bounds check. Subsequently, out-of-bounds reads may occur when decoding this part. This patch switches the multiplication to use check_mul_overflow() to abort processing the osdmap if an overflow occurred. Therefore, osdmaps/messages containing large values for len that result in a multiplication overflow are treated as invalid. [ idryomov: rename new_state_len -> new_state_item_size, formatting ]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68433", "url": "https://ubuntu.com/security/CVE-2026-68433", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: bound get_version reply decode to front len handle_get_version_reply() uses msg->front_alloc_len as the decode boundary for MON_GET_VERSION_REPLY. That is the size of the reused reply buffer, not the number of bytes actually received. A truncated reply can therefore pass ceph_decode_need() and decode the second u64 from stale tail bytes left in the buffer by an earlier message, causing an uninitialized memory read. Use msg->front.iov_len as the receive-side decode boundary, matching other libceph reply handlers and limiting decoding to the bytes that were actually read from the wire.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68160", "url": "https://ubuntu.com/security/CVE-2026-68160", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: fix pre-auth out-of-bounds read on snaptrace in ceph_handle_caps() ceph_handle_caps() reads snap_trace_len from the wire-format ceph_mds_caps header and uses it unconditionally to build a fake end pointer (snaptrace + snaptrace_len) that is later handed to ceph_update_snap_trace() in the CEPH_CAP_OP_IMPORT case: snaptrace = h + 1; snaptrace_len = le32_to_cpu(h->snap_trace_len); p = snaptrace + snaptrace_len; ... case CEPH_CAP_OP_IMPORT: if (snaptrace_len) { ... if (ceph_update_snap_trace(mdsc, snaptrace, snaptrace + snaptrace_len, false, &realm)) { ... } ceph_update_snap_trace() then decodes a struct ceph_mds_snap_realm from snaptrace using ceph_decode_need(&p, e, sizeof(*ri), bad) with the attacker-supplied fake end e == snaptrace + snaptrace_len. With snaptrace_len == 0xFFFFFFFF the bound check is trivially satisfied, ri = p reads sizeof(struct ceph_mds_snap_realm) past the legitimate msg->front buffer, and ri->num_snaps / ri->num_prior_parent_snaps then drive further out-of-bounds reads of the encoded snap arrays. The eleven msg_version >= 2 .. msg_version >= 12 decoder blocks above the op switch each catch this OOB through their ceph_decode_*_safe() / ceph_decode_need() helpers, but they sit behind a hdr.version-gated if, so a malicious or compromised MDS that sets msg->hdr.version = 1 reaches the IMPORT path with no version-gated decoder having validated snap_trace_len. The shape has been present since ceph_handle_caps() was introduced. Validate snap_trace_len against the message front buffer before consuming it, using the canonical ceph_decode_need() / ceph_has_room() helper. The helper bounds the length with subtraction (n <= end - p, guarded by end >= p) rather than pointer addition, so it is wrap-safe for the attacker-controlled u32 length on 32-bit builds where p + snap_trace_len could overflow the address space. This matches the rest of the ceph decode path (e.g. the pool_ns_len check a few lines below), and the existing goto bad cleanup already covers this exit path.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68175", "url": "https://ubuntu.com/security/CVE-2026-68175", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix resource leak on mmiotrace trace_pipe close The mmiotrace tracer was added May 12th 2008. At that time, resources created in pipe_open() could not be freed because there was not pipe_close function pointer of the tracer. The pipe_close function pointer was added in December 7th, 2009, but the mmiotrace tracer was not updated. mmio_pipe_open() allocates a header_iter and takes a pci_dev reference when trace_pipe is opened. mmio_close() frees them, but it was only wired to the tracer's .close callback. tracing_release_pipe() invokes .pipe_close, not .close, when the trace_pipe file is released. As a result, closing trace_pipe with the mmiotrace tracer active leaked the header_iter allocation and left a stale pci_dev reference. Set .pipe_close to mmio_close, matching how function_graph wires both callbacks to the same handler. Note, if the trace_pipe is read to completion, it will clean up the resources, but if one were to run: # head -n 1 /sys/kernel/tracing/trace_pipe VERSION 20070824 Over and over again, it would trigger a massive leak.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68176", "url": "https://ubuntu.com/security/CVE-2026-68176", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix mmiotrace possible NULL dereferencing of hiter->dev If the mmio_pipe_open() fails to find a PCI device, the hiter->dev will be assigned to NULL. The mmiotrace read() function dereferences the hiter->dev if hiter exists. Change the test of the read to not only check hiter being NULL, but also the hiter->dev before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68180", "url": "https://ubuntu.com/security/CVE-2026-68180", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: intel_th: fix MSC output device reference leak intel_th_output_open() looks up the output device with bus_find_device_by_devt(), which returns the device with a reference that must be dropped after use. commit 95fc36a234da (\"intel_th: fix device leak on output open()\") attempted to drop the reference from intel_th_output_release(). However, a successful open replaces file->f_op with the output driver file operations before returning, so close runs the output driver release callback instead. For MSC outputs, close runs intel_th_msc_release(), which only removes the per-file iterator and does not drop the device reference taken by intel_th_output_open(). Consequently, every successful MSC output open leaks one device reference. Drop the device reference from intel_th_msc_release(), which is the release path actually used for MSC output files. Remove the now-unused intel_th_output_release() callback from intel_th_output_fops.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68181", "url": "https://ubuntu.com/security/CVE-2026-68181", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mei: bus: access mei_device under device_lock on cleanup Fix couple of problems in mei_cl_bus_dev_release(): mei_cl_flush_queues() is running without lock. bus->file_list access after mei_dev_bus_put(bus) can become a use-after-free if this was the last reference to bus. Protect queues cleanup and WARN traversal by device lock there to avoid the concurrent access problems. Move WARN traversal before mei_dev_bus_put(bus). This file uses bus variable name for mei_device, adjust code of mei_cl_bus_dev_release() to use bus variable too.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68182", "url": "https://ubuntu.com/security/CVE-2026-68182", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: comedi: comedi_parport: deal with premature interrupt Syzbot reported a general protection fault in `comedi_get_is_subdevice_running()`, which was called from the interrupt handler `parport_interrupt()` in the \"comedi_parport\" driver, but it does not currently have a C reproducer for the problem. It's probably due to a premature interrupt for one of two reasons: 1. The driver sets up the interrupt handler before the comedi subdevices used by the interrupt handler have been allocated, but does not disable the interrupt in the parallel port's CTRL register first. 2. The driver uses a user-supplied I/O port base address which Syzbot would have supplied, but it might not be backed by real parallel port hardware. Change the initialization order in the driver's comedi \"attach\" handler (`parport_attach()`) so that the hardware registers are initialized before the interrupt handler is requested. This should prevent premature interrupts occurring for real hardware. Also add a test to the interrupt handler to ensure the comedi device is fully attached and return early if it isn't.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68184", "url": "https://ubuntu.com/security/CVE-2026-68184", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cdrom: fix stack out-of-bounds read in CDROMVOLCTRL mmc_ioctl_cdrom_volume() first reads the audio control mode page into a 32-byte stack buffer with cgc->buflen set to 24. If the device reports a block descriptor, the function increases cgc->buflen to include that descriptor and reads the page again. For CDROMVOLCTRL, the function then builds a MODE SELECT parameter list by moving cgc->buffer forward by offset - 8 bytes. This drops the block descriptor from the outgoing payload and leaves a new 8-byte mode parameter header in front of the audio control page. However, cgc->buflen is left unchanged. With a standard 8-byte block descriptor, cgc->buffer points at buffer + 8 but cgc->buflen remains 32. cdrom_mode_select() therefore asks the low level packet path to write 32 bytes from that adjusted pointer, reading 8 bytes past the end of the 32-byte stack buffer. This is not hit by CDROMVOLREAD, and CDROMVOLCTRL only triggers it on drives that return a non-zero block descriptor length, which helps explain why it has gone unnoticed. The overread is also sent to the device as extra MODE SELECT payload, so it may not produce an obvious local failure. Reduce cgc->buflen by the same amount as the buffer pointer adjustment so the MODE SELECT transfer covers only the intended parameter list.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68186", "url": "https://ubuntu.com/security/CVE-2026-68186", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: binfmt_misc: set have_execfd only once the interpreter is opened load_misc_binary() raises bprm->have_execfd as soon as it sees the 'O' (or 'C') flag. This happens well before it opens the interpreter. If that open fails the flag stays set on the bprm. binfmt_misc is at the head of the format list so an interpreter open failure that returns -ENOEXEC lets the search fall through to a later format. This means it runs the matched binary directly having never staged an interpreter. So bprm->executable is NULL while have_execfd falsely claims a descriptor is present. Consequently, begin_new_exec() dereferences the missing executable: would_dump(bprm, bprm->executable); and NULL derefs. Had it not, the hand-off later in the same function would have failed anyway. FD_ADD(0, bprm->executable) rejects a NULL file with -ENOMEM. Both sites are past the point of no return so the exec cannot be unwound either way. This can be reached by unprivileged users as binfmt_misc can be mounted in user namespaces. So a user can register an 'O' entry whose interpreter lives on a FUSE mount, have the FUSE server fail the open with -ENOEXEC and execute a native ELF file that matches the entry. have_execfd only means anything alongside the executable it describes which is not set until the interpreter has been opened and staged. So lets raise it there, next to execfd_creds, which is already set at that point. An open failure now leaves it clear, so the fallback format derives credentials from the binary and emits no AT_EXECFD, as it would for any native exec. The argv rewrite load_misc_binary() performs before the open is still not undone. This means the binary sees the interpreter path in argv[0] and its own path in argv[1] but that predates this change and only became observable once the exec stopped faulting.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68187", "url": "https://ubuntu.com/security/CVE-2026-68187", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exec: fix unsigned loop counter wrap in transfer_args_to_stack() The stop value is derived from bprm->p >> PAGE_SHIFT. The index variable is an unsigned long. If bprm->p drops below PAGE_SIZE and stop becomes zero the loop condition index >= stop is always true. After the index == 0 iteration the decrement wraps to ULONG_MAX and bprm->page[ULONG_MAX] reads sizeof(void *) bytes in front of the array. The pointer has wrapped to -1. That garbage pointer is then passed to kmap_local_page() and PAGE_SIZE bytes are copied from wherever that lands into the stack of the process being created. And the loop doesn't terminate either... Getting there only requires bprm->p < PAGE_SIZE. On !MMU bprm_set_stack_limit() and bprm_hit_stack_limit() are empty. So the only constraint on how far bprm->p is pushed down is valid_arg_len(), i.e. that each individual string still fits in what is left. bprm->p starts at PAGE_SIZE * MAX_ARG_PAGES - sizeof(void *) so a single argument or environment string of a little over 31 pages leaves it in the first page: Oops - load access fault [#1] CPU: 0 UID: 0 PID: 1 Comm: victim Not tainted 7.2.0-rc4 #1 epc : __memcpy+0xd4/0xf8 ra : transfer_args_to_stack+0xaa/0xae s4 : ffffffffffffffff s2 : 0000000000000000 a1 : ffffffdc98000000 a2 : 0000000000001000 status: 0000000a00001880 badaddr: ffffffdc98000000 cause: 0000000000000005 [<801a5324>] __memcpy+0xd4/0xf8 [<800d5f6a>] load_flat_binary+0x43a/0x65e [<800a2de4>] bprm_execve+0x1d4/0x316 [<800a351a>] do_execveat_common+0x12e/0x138 [<800a3d44>] __riscv_sys_execve+0x38/0x4e Kernel panic - not syncing: Fatal exception in interrupt This is an arcane bug but we should still fix it. Count down from MAX_ARG_PAGES so the loop ends when index reaches stop, stop == 0 included. The iterations performed are unchanged for every other value of stop. Only CONFIG_MMU=n builds are affected, transfer_args_to_stack() is used by binfmt_flat and binfmt_elf_fdpic on nommu only. The loop predates git history. commit 7e7ec6a93434 (\"elf_fdpic_transfer_args_to_stack(): make it generic\") only moved it from binfmt_elf_fdpic.c into fs/exec.c and narrowed the copy to the used part of the first page. The condition and the decrement are unchanged from 2.6.12-rc2.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68188", "url": "https://ubuntu.com/security/CVE-2026-68188", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: Fix session UAF in set_termios rfcomm_tty_set_termios() tests dlc->session without rfcomm_mutex and later passes the pointer to rfcomm_send_rpn(). The latter dereferences both session->initiator and session->sock. Meanwhile, krfcommd can unlink the DLC and free the session while holding rfcomm_mutex. The race can proceed as follows: TTY ioctl task krfcommd -------------- -------- load dlc->session enter rfcomm_send_rpn() lock rfcomm_mutex clear dlc->session free session unlock rfcomm_mutex read session->initiator KASAN reported: BUG: KASAN: slab-use-after-free in rfcomm_send_rpn+0x297/0x2a0 Read of size 4 at addr ffff88810012a850 by task poc/92 Call Trace: rfcomm_send_rpn+0x297/0x2a0 rfcomm_tty_set_termios+0x50d/0x850 tty_set_termios+0x596/0x950 set_termios+0x46a/0x6e0 tty_mode_ioctl+0x152/0xbd0 tty_ioctl+0x915/0x1240 __x64_sys_ioctl+0x134/0x1c0 Allocated by task 92: rfcomm_session_add+0x9e/0x2e0 rfcomm_dlc_open+0x8b1/0xe00 rfcomm_dev_activate+0x85/0x1a0 rfcomm_tty_open+0x90/0x280 Freed by task 68: kfree+0x131/0x3c0 rfcomm_session_del+0x119/0x180 rfcomm_run+0x737/0x4710 Add rfcomm_dlc_send_rpn(), which holds rfcomm_mutex while it verifies that the DLC is still attached and sends the RPN frame. Have the TTY path use the helper and drop its unlocked session check. This keeps the session valid through both the frame construction and socket send.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68189", "url": "https://ubuntu.com/security/CVE-2026-68189", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: Protect UUID list traversal The hci_sync conversion moved class-of-device and EIR generation from an HCI request built under hdev->lock to asynchronous command sync work. The worker holds hdev->req_lock, but that lock does not serialize access to hdev->uuids against add_uuid() and remove_uuid(), which update the list under hdev->lock. The following interleaving can therefore occur: CPU0 (command sync work) CPU1 (management socket) fetch uuid from the list list_del(&uuid->list) kfree(uuid) read uuid->size KASAN reports the resulting use-after-free: BUG: KASAN: slab-use-after-free in eir_create+0xb8f/0xee0 Read of size 1 at addr ffff88810dbd8620 by task kworker/u17:0/87 Workqueue: hci0 hci_cmd_sync_work Call Trace: eir_create+0xb8f/0xee0 hci_update_eir_sync+0x1c0/0x330 hci_cmd_sync_work+0x13c/0x290 process_one_work+0x63a/0x1070 worker_thread+0x45b/0xd10 Allocated by task 86: __kasan_kmalloc+0x8f/0xa0 add_uuid+0x18a/0x4b0 hci_sock_sendmsg+0x1033/0x1ea0 Freed by task 92: __kasan_slab_free+0x43/0x70 kfree+0x131/0x3c0 remove_uuid+0x25e/0x560 hci_sock_sendmsg+0x1033/0x1ea0 Hold hdev->lock while generating and committing the class-of-device and EIR snapshots. Release it before sending an HCI command, so controller waits do not happen under the device lock. This protects all UUID list walks in these paths and restores the serialization lost in the command sync conversion.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68190", "url": "https://ubuntu.com/security/CVE-2026-68190", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix OOB reads in rtw_get_wps_ie() rtw_get_wps_ie() iterates over IE data from network frames without validating that the IE header and payload fit within the remaining buffer before reading them. Specifically: - in_ie[cnt + 1] is read without checking cnt + 1 < in_len - memcmp(&in_ie[cnt + 2], ...) accesses cnt + 2 without bounds check - in_ie[cnt + 1] is used as length without verifying payload fits Add bounds checks at the top of the loop body to break early if fewer than 2 bytes remain for the IE header, or if the declared payload extends past the end of the buffer. Also require at least 4 bytes of payload before comparing the WPS OUI.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68192", "url": "https://ubuntu.com/security/CVE-2026-68192", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: make release_scratchbuffers idempotent brcmf_pcie_release_scratchbuffers() frees the shared.scratch and shared.ringupd DMA buffers with dma_free_coherent() but does not clear the pointers afterwards, unlike the sibling release_ringbuffers() which NULLs commonrings/flowrings/idxbuf on release. Both the bus_reset .reset callback (brcmf_pcie_reset) and brcmf_pcie_remove() call release_scratchbuffers. When reset teardown has run before removal, remove's own teardown would call dma_free_coherent() a second time on the already-freed DMA allocation. NULL the pointers after free, matching release_ringbuffers(), so a later release observes that the allocation has already been released. This patch makes repeated sequential release safe; the reset-work lifetime is handled separately by the following patch. This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68194", "url": "https://ubuntu.com/security/CVE-2026-68194", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7921: drop TXRX_NOTIFY on non-mmio buses PKT_TYPE_TXRX_NOTIFY is an mmio-only event, but mt7921_rx_check() and mt7921_queue_rx_skb() dispatch it to mt7921_mac_tx_free() on every bus. mt7921_mac_tx_free() cleans the DMA tx queues with mt76_queue_tx_cleanup(), which calls queue_ops->tx_cleanup(). Only the mmio queue ops implement that callback; on USB and SDIO it is NULL, so a TXRX_NOTIFY there calls a NULL pointer in the RX worker: BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:0x0 Call Trace: mt7921_mac_tx_free+0x64/0x310 [mt7921_common] mt7921_rx_check+0x5f/0xf0 [mt7921_common] mt76u_rx_worker+0x1b9/0x620 [mt76_usb] Drop the event on non-mmio buses via mt76_is_mmio(), as in commit 5683e1488aa9 (\"wifi: mt76: connac: do not check WED status for non-mmio devices\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68195", "url": "https://ubuntu.com/security/CVE-2026-68195", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7615: drop TXRX_NOTIFY on non-mmio buses PKT_TYPE_TXRX_NOTIFY is an mmio-only event, but mt7615_rx_check() and mt7615_queue_rx_skb() dispatch it to mt7615_mac_tx_free() on every bus. mt7615_mac_tx_free() cleans the DMA tx queues with mt76_queue_tx_cleanup(), which calls queue_ops->tx_cleanup(). Only the mmio queue ops implement that callback; on the mt7663 USB and SDIO buses it is NULL, so a TXRX_NOTIFY there calls a NULL pointer in the RX worker. Same defect as the mt7921 and mt7925 patches in this series. Drop the event on non-mmio buses via mt76_is_mmio(), as in commit 5683e1488aa9 (\"wifi: mt76: connac: do not check WED status for non-mmio devices\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68196", "url": "https://ubuntu.com/security/CVE-2026-68196", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: wilc1000: validate assoc response length before subtracting header wilc_parse_assoc_resp_info() computes the trailing IE length as \ties_len = buffer_len - sizeof(*res); without first checking that buffer_len is at least sizeof(struct wilc_assoc_resp) (6 bytes). buffer_len is the length reported for a received association response (host_int_parse_assoc_resp_info() passes hif_drv->assoc_resp / assoc_resp_info_len straight in) and must be validated before the driver accesses the fixed header. For a frame shorter than the 6-byte fixed header, the subtraction wraps. For a four-byte response the result is truncated to a u16 ies_len of 65534, so kmemdup() then attempts to copy 65534 bytes starting at buffer + sizeof(*res), beyond the valid association-response data (CWE-125). A response shorter than four bytes can also cause an out-of-bounds read of res->status_code at offsets 2 and 3. Reject frames too short to hold the fixed header before touching the header or computing ies_len. Also set the connection status to a failure on this path: the caller falls through to a \"conn_info->status == WLAN_STATUS_SUCCESS\" check after the parser returns, so leaving the status untouched could let a malformed short response be treated as a successful association.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68197", "url": "https://ubuntu.com/security/CVE-2026-68197", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: fix NULL dereference when the AP has HT-cap but no HT-oper mwifiex_tdls_add_ht_oper() gates its follow-the-AP-bandwidth path on bss_desc->bcn_ht_cap being present, but then dereferences a different pointer, bss_desc->bcn_ht_oper: \tif (ISSUPP_CHANWIDTH40(priv->adapter->hw_dot_11n_dev_cap) && \t bss_desc->bcn_ht_cap && \t ISALLOWED_CHANWIDTH40(bss_desc->bcn_ht_oper->ht_param)) bcn_ht_cap and bcn_ht_oper are populated independently while parsing the associated AP's beacon in mwifiex_update_bss_desc_with_ie(): an AP that advertises an HT Capabilities element but no HT Operation element leaves bcn_ht_cap non-NULL and bcn_ht_oper NULL. Setting up a TDLS link to a peer while associated to such an AP then dereferences the NULL bcn_ht_oper and crashes the kernel. Every other bcn_ht_oper user in the driver NULL-checks it first. Guard on the pointer that is actually dereferenced. Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68199", "url": "https://ubuntu.com/security/CVE-2026-68199", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: fix OOB access from firmware ADDBA window size aggr_recv_addba_req_evt() logs a debug message when the firmware-supplied win_sz is outside [AGGR_WIN_SZ_MIN, AGGR_WIN_SZ_MAX] but does not return. The out-of-range win_sz is then used in TID_WINDOW_SZ() to compute a kzalloc size and stored in rxtid->hold_q_sz, leading to zero-size or overflowed allocations and subsequent out-of-bounds access. Clean up any previously active aggregation session for the TID first, then return early when win_sz is out of the valid range, instead of proceeding with a broken allocation size.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68202", "url": "https://ubuntu.com/security/CVE-2026-68202", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: seq: close a re-opened queue timer in the destructor queue_delete() closes the queue timer, then frees it. snd_seq_timer_close() clears q->timer->timeri. snd_use_lock_sync() then drains borrowers, and snd_seq_timer_delete() frees q->timer. A borrower can re-open the timer inside that window. A SET_QUEUE_CLIENT that took a queueptr() use_lock reference before the queue was unlinked runs snd_seq_timer_open() after the close. Open refuses re-open only while timeri is set, and the close just cleared it, so it re-opens timeri. snd_seq_timer_delete() does not close that instance. Its snd_seq_timer_stop() is a no-op, because running was cleared first. So it frees q->timer with the instance still live. The queue is freed next. The instance stays on the global timer with callback_data pointing at the freed queue. A non-owner START on the unlocked queue arms it. The next tick derefs the freed queue in snd_seq_timer_interrupt(). Reachable by an unprivileged user with access to /dev/snd/seq. No CAP and no queue ownership required. Close any lingering instance in the destructor. There, ->timeri can no longer change: the queue is unlinked and all use_lock borrowers have drained, so no snd_seq_queue_use() can re-open it. Close it before clearing q->timer. snd_timer_close() waits for any in-flight snd_seq_timer_interrupt() to finish, and that callback still reads q->timer (via snd_seq_check_queue()), so q->timer must stay valid until it drains.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68204", "url": "https://ubuntu.com/security/CVE-2026-68204", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: vivid: check for vb2_is_busy() when toggling caps The vivid_update_format_cap/out() functions must only be called if the capture/output queue are not busy. But for the controls that select the CROP/COMPOSE/SCALE capability that is not checked. Only when streaming starts will they be set to 'grabbed' and it is impossible to change the control, but between REQBUFS and STREAMON you are still allowed to set these controls. Since vivid_update_format_cap/out will change the format, this can cause unexpected results. Besides adding these checks, also add a WARN_ON in vivid_update_format_cap/out() if the queue is busy. I'm 90% certain that this is the cause of this syzbot bug: https://syzkaller.appspot.com/bug?extid=dac8f5eaa46837e97b89 But since we never have reproducers, it is hard to be certain. In any case, these checks are needed regardless.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68206", "url": "https://ubuntu.com/security/CVE-2026-68206", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: v4l2-ctrls: validate HEVC active reference counts HEVC slice parameters are shared stateless V4L2 controls, but the common validation path does not verify the active L0/L1 reference counts before driver-specific code consumes them. The original report came from Cedrus, but the active count bounds are not Cedrus-specific. Validate them in the common HEVC slice control path so stateless HEVC drivers get the same basic guarantees as soon as the control is queued. Do not reject ref_idx_l0/ref_idx_l1 entries here. Existing userspace may use out-of-range sentinel values such as 0xff for missing references, and some hardware can use that information for concealment. Keep this common check limited to the active reference counts.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68207", "url": "https://ubuntu.com/security/CVE-2026-68207", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: ti: vpe: unwind v4l2 device registration on probe error If the vpe_top resource is missing, vpe_probe() returns -ENODEV after v4l2_device_register() has succeeded. Probe failures do not call the driver's remove callback, so the v4l2 device remains registered on that error path. Route that failure through the existing v4l2_device_unregister() unwind label, matching the other errors after v4l2_device_register().", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68209", "url": "https://ubuntu.com/security/CVE-2026-68209", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: sun4i-csi: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. sun4i_csi_start_streaming() returned -EINVAL when no matching CSI format could be found, before any setup (scratch buffer allocation, pipeline start) had been performed. The remaining error paths already converge on the err_clear_dma_queue label, which calls return_all_buffers(..., VB2_BUF_STATE_QUEUED) under csi->qlock. Jump to that label directly: the intermediate err_disable_device / err_disable_pipeline / err_free_scratch_buffer labels are skipped, which is correct because nothing they would undo has happened yet. This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68210", "url": "https://ubuntu.com/security/CVE-2026-68210", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: stm32: dcmi: unregister notifier on probe failure dcmi_graph_init() registers the async notifier before dcmi_probe() toggles the reset line. If reset_control_assert() or reset_control_deassert() fails afterwards, probe returns through err_cleanup and the driver core will not call dcmi_remove(). Unregister the notifier before cleaning it up on that error path, matching the successful remove path and the V4L2 async notifier lifetime rules. [hverkuil: added Fixes tag]", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68212", "url": "https://ubuntu.com/security/CVE-2026-68212", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: saa7134: Fix a possible memory leak in saa7134_video_init1 In saa7134_video_init1(), the return value of the first saa7134_pgtable_alloc() is not checked. If it fails, the function continues as if successful, leaving the driver with an invalid page table. Additionally, if vb2_queue_init() for the VBI queue fails after the video queue page table has been allocated, the allocated memory is not freed before returning. The second saa7134_pgtable_alloc() also lacks a return value check. Errors occur during device probing before the device is fully registered, the normal cleanup path in saa7134_finidev() is not executed, leading to memory leaks and potential use of uninitialized DMA resources. Check the return value of both saa7134_pgtable_alloc() calls and propagate errors. On failure of any later step, free allocated page tables to avoid memory leaks. Ensure control handlers are also released on error to prevent further resource leakage. Found by code review.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68213", "url": "https://ubuntu.com/security/CVE-2026-68213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: rtl2832_sdr: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. rtl2832_sdr_start_streaming() had multiple error paths that hit this trap: two direct early returns (-ENODEV, -ERESTARTSYS), plus six `goto err` paths covering subdev s_power, tuner setup, ADC setup, stream-buffer allocation, urb allocation, and urb submission failures. None of them returned the queued buffers. The original function had no distinct success exit and fell straight through into the err label, which previously only did mutex_unlock and \"return ret\". Adding queued-buffer cleanup at err must therefore be paired with an explicit success return; otherwise every successful start would also drain the buffer queue and kill streaming. Add that success return, then add rtl2832_sdr_cleanup_queued_bufs() at the err label and before each early return. The cleanup helper takes a vb2_buffer_state argument so that the start_streaming error paths can pass VB2_BUF_STATE_QUEUED (as expected by userspace on start_streaming failure) while stop_streaming keeps its existing VB2_BUF_STATE_ERROR semantics. This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\"). The err label still does not roll back power_ctrl(), frontend_ctrl(), the POWER_ON flag, or stream/URB allocations that may have happened before the failing step. Those are pre-existing leaks of a different class and are not addressed here.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68214", "url": "https://ubuntu.com/security/CVE-2026-68214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: rtl2832: fix use-after-free in rtl2832_remove() cancel_delayed_work_sync() is called before i2c_mux_del_adapters() in rtl2832_remove(). While the cancel waits for any running instance of i2c_gate_work to finish, it does not prevent the timer from being rescheduled by a concurrent thread. During probe, the r820t_attach() call attempts I2C transfers through the mux adapter. These transfers go through i2c_mux_master_xfer(), which calls rtl2832_deselect() after the transfer completes, rescheduling i2c_gate_work via schedule_delayed_work(). If this transfer is still in flight when rtl2832_remove() runs, rtl2832_deselect() can reschedule i2c_gate_work after it has been cancelled, causing a use-after-free when kfree(dev) is called. Fix this by calling i2c_mux_del_adapters() before cancel_delayed_work_sync(). Once the mux adapter is unregistered, no new I2C transfers can go through it, so rtl2832_deselect() can no longer reschedule i2c_gate_work. The subsequent cancel_delayed_work_sync() is then guaranteed to be final.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68215", "url": "https://ubuntu.com/security/CVE-2026-68215", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: radio-si476x: Unregister v4l2_device on probe failure si476x_radio_probe() registers radio->v4l2dev before allocating the V4L2 controls and before registering the video device. If any of those later steps fails, probe returns through the exit label after freeing only the control handler. A failed probe does not call si476x_radio_remove(), so the v4l2_device_unregister() there is not reached. This leaves the parent device reference taken by v4l2_device_register() behind on the error path. Unregister the V4L2 device in the probe error path after freeing the controls.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68216", "url": "https://ubuntu.com/security/CVE-2026-68216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: pwc: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. pwc's start_streaming() had two early returns that hit this trap: -ENODEV when the USB device was already disconnected, and -ERESTARTSYS when mutex_lock_interruptible() was interrupted by a signal. Call the existing pwc_cleanup_queued_bufs() helper with VB2_BUF_STATE_QUEUED before returning (matching the state already used by the pwc_isoc_init() error path in the same function). This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68217", "url": "https://ubuntu.com/security/CVE-2026-68217", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: pwc: Drain fill_buf on start_streaming() failure pwc_isoc_init() submits its isochronous URBs with usb_submit_urb(.., GFP_KERNEL) in a loop. After the first URB is submitted, its completion handler pwc_isoc_handler() can run on another CPU before the loop finishes: start_streaming() pwc_isoc_init() usb_submit_urb(urbs[0], GFP_KERNEL) pwc_isoc_handler(urbs[0]) pdev->fill_buf = pwc_get_next_fill_buf(pdev) usb_submit_urb(urbs[i>0], ..) -> fails pwc_isoc_cleanup(pdev) /* kills URBs */ return ret; pwc_cleanup_queued_bufs(pdev, VB2_BUF_STATE_QUEUED) pwc_get_next_fill_buf() detaches a buffer from pdev->queued_bufs and stores it in pdev->fill_buf. The error path in start_streaming() only drains pdev->queued_bufs, so the buffer parked in pdev->fill_buf is leaked. vb2_start_streaming() then triggers WARN_ON(owned_by_drv_count). stop_streaming() already handles this since commit 80b0963e1698 (\"[media] pwc: fix WARN_ON\"), which added the fill_buf drain in the teardown path but not in the start_streaming() error path. Mirror that handling on failure so start_streaming() returns with no buffer owned by the driver. Issue identified by automated review of the INV-003 series at https://sashiko.dev/", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68218", "url": "https://ubuntu.com/security/CVE-2026-68218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: pci: dm1105: Free allocated workqueue Destroy allocated workqueue in remove() callback to free its resources, thus fixing memory leak.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68219", "url": "https://ubuntu.com/security/CVE-2026-68219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: nxp: imx8-isi: Fix potential out-of-bounds issues The maximum downscaling factor supported by ISI can be up to 16. Add minimum value constraint before applying the setting to hardware. Otherwise, the process will not respond even when Ctrl+C is executed.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68220", "url": "https://ubuntu.com/security/CVE-2026-68220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: nxp: imx8-isi: Add missing v4l2_subdev_cleanup() in crossbar and pipe Both mxc_isi_crossbar_init() and mxc_isi_pipe_init() call v4l2_subdev_init_finalize() which allocates the subdev active state, but neither mxc_isi_crossbar_cleanup() nor mxc_isi_pipe_cleanup() calls v4l2_subdev_cleanup() to free it. This causes a memory leak on every rmmod, reported by kmemleak: unreferenced object 0xffff0000d06fc800 (size 192): comm \"(udev-worker)\", pid 254, jiffies 4294913455 backtrace (crc 36eeae58): kmemleak_alloc+0x34/0x40 __kvmalloc_node_noprof+0x5f8/0x7d8 __v4l2_subdev_state_alloc+0x1fc/0x30c __v4l2_subdev_init_finalize+0x178/0x368 Add the missing v4l2_subdev_cleanup() calls before media_entity_cleanup() in both crossbar and pipe cleanup paths.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68222", "url": "https://ubuntu.com/security/CVE-2026-68222", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: msi2500: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. msi2500_start_streaming() had five error paths that all hit this trap and were further tangled by ret-overwriting between calls: - -ENODEV when the USB device was already disconnected - -ERESTARTSYS when mutex_lock_interruptible() was interrupted - msi2500_set_usb_adc() failure: ret was silently overwritten by the next call (msi2500_isoc_init), so the error was lost entirely - msi2500_isoc_init() failure: cleanup_queued_bufs was called, but the function then fell through to msi2500_ctrl_msg() and again masked the original error by overwriting ret - msi2500_ctrl_msg(CMD_START_STREAMING) failure: no cleanup at all, leaving isoc URBs submitted with no way for the driver to consume them Consolidate the error paths into a small goto chain. Every failure now stops the function, drains the queued-buffer list, and returns the real error code. The ctrl_msg failure path also rolls back the preceding msi2500_isoc_init() via msi2500_isoc_cleanup() before unlocking and draining. The cleanup helper takes a vb2_buffer_state argument so that the start_streaming error paths can pass VB2_BUF_STATE_QUEUED (as expected by userspace on start_streaming failure) while stop_streaming keeps its existing VB2_BUF_STATE_ERROR semantics. This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68223", "url": "https://ubuntu.com/security/CVE-2026-68223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: meson: vdec: Fix memory leak in error path of vdec_open The vdec_open() function previously jumped directly to err_m2m_release when vdec_init_ctrls() failed, skipping release of the m2m context. This caused a resource leak. Fix it by introducing a proper err_m2m_ctx_release label that calls v4l2_m2m_ctx_release(sess->m2m_ctx) before releasing the m2m device. This was identified via kmemleak: unreferenced object 0xffff0000205d6878 (size 8): comm \"v4l_id\", pid 5289, jiffies 4294938580 hex dump (first 8 bytes): 40 d2 49 18 00 00 ff ff @.I..... backtrace (crc d3204599): kmemleak_alloc+0xc8/0xf0 __kvmalloc_node_noprof+0x60c/0x850 v4l2_ctrl_handler_init_class+0x1b4/0x2e8 [videodev] vdec_open+0x1f4/0x788 [meson_vdec] v4l2_open+0x144/0x460 [videodev] chrdev_open+0x1ac/0x500 do_dentry_open+0x3f0/0xfe8 vfs_open+0x68/0x320 do_open+0x2d8/0x9a8 path_openat+0x1d0/0x4f0 do_filp_open+0x190/0x380 do_sys_openat2+0xf8/0x1b0 __arm64_sys_openat+0x13c/0x1e8 invoke_syscall+0xdc/0x268 el0_svc_common.constprop.0+0x178/0x258 do_el0_svc+0x4c/0x70", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68226", "url": "https://ubuntu.com/security/CVE-2026-68226", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cx23885: add ioremap return check and cleanup Add a check for the return value of pci_ioremap_bar() in cx23885_dev_setup(). If ioremap for BAR0 fails, release the already allocated PCI memory region, decrement the device count, and return -ENODEV. This prevents a potential null pointer dereference and ensures proper cleanup on memory mapping failure.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68227", "url": "https://ubuntu.com/security/CVE-2026-68227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cx231xx: 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 driver state lifetime so that it is released on driver unbind.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68229", "url": "https://ubuntu.com/security/CVE-2026-68229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cedrus: skip invalid H.264 reference list entries Cedrus consumes H.264 ref_pic_list0/ref_pic_list1 entries from the stateless slice control and later uses their indices to look up decode->dpb[] in _cedrus_write_ref_list(). Rejecting such controls in cedrus_try_ctrl() would break existing userspace, since stateless H.264 reference lists may legitimately carry out-of-range indices for missing references. Instead, guard the actual DPB lookup in Cedrus and skip entries whose indices do not fit the fixed V4L2_H264_NUM_DPB_ENTRIES array. This keeps the fix local to the driver use site and avoids out-of-bounds reads from malformed or unsupported reference list entries.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68231", "url": "https://ubuntu.com/security/CVE-2026-68231", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: airspy: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. airspy_start_streaming() returned -ENODEV early when the USB device had been disconnected (s->udev == NULL) without returning any buffers that buf_queue() had already accepted. Take v4l2_lock first and jump to the existing err_clear_bit label, which already drains s->queued_bufs via vb2_buffer_done(..., VB2_BUF_STATE_QUEUED) before unlocking. This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68445", "url": "https://ubuntu.com/security/CVE-2026-68445", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vc4: Prevent shader BO mappings from becoming writable vc4_gem_object_mmap() rejects a writable mapping of a validated shader BO, but leaves VM_MAYWRITE set. Userspace can map the BO read-only and then turn it writable with mprotect(). Validated shader BOs must stay read-only: the validator checks the instructions once and the GPU trusts them afterwards. A writable mapping lets userspace rewrite the code after validation, bypassing the validator. Clear VM_MAYWRITE on the read-only path so the mapping cannot be upgraded, as i915 already does for its read-only objects.", "cve_priority": "high", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68446", "url": "https://ubuntu.com/security/CVE-2026-68446", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: Validate vmw_surface_metadata::array_size This field comes from userspace and should be validated against specific limits depending on which Shader Model (SM) is available.", "cve_priority": "high", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68234", "url": "https://ubuntu.com/security/CVE-2026-68234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix bo->pin leaking in amdgpu_bo_create_reserved amdgpu_bo_create_reserved() only allocates a new BO when *bo_ptr (struct amdgpu_bo **bo_ptr as input parameter) is NULL, it simply skips creation when *bo_ptr is non-NULL. But it unconditionally reserves, pins, gart allocates and maps the BO afterwards. When the same non-NULL BO pointer is passed in again, for example firmware buffers that live in adev and are re-loaded on every resume / cp_resume / start under AMDGPU_FW_LOAD_DIRECT, amdgpu_bo_pin() just increases pin_count unconditionally, however the matching teardown only unpins once, so pin_count never drops to zero, so TTM is not able to move, swap or evict a BO, causing BO leaks. This commit fixes this issue by only pinning the bo once at creation, and repeated calls no longer take additional pin references. (cherry picked from commit 3ddc0ae76202c447b6aec61e907b852bc94671cf)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68236", "url": "https://ubuntu.com/security/CVE-2026-68236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: set new_stream to NULL after release In dm_update_crtc_state(), the skip_modeset path releases new_stream via dc_stream_release() but does not set the pointer to NULL. If a later error (e.g., color management failure) triggers the fail label, the error path calls dc_stream_release() again on the same dangling pointer, causing a double release and potential use-after-free. Fix this by setting new_stream to NULL after the initial release. (cherry picked from commit 99f3af19073b3ddbfd96e789124cce12c4277b28)", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68243", "url": "https://ubuntu.com/security/CVE-2026-68243", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/gem: Fix NULL deref in I915_CONTEXT_PARAM_SSEU Setting context engine slot N into I915_ENGINE_CLASS_INVALID / I915_ENGINE_CLASS_INVALID_NONE and attempting to apply I915_CONTEXT_PARAM_SSEU to the same slot N will deref NULL. Fix that. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 36eda5b5c2d40da41cc0a5403c26986237cf9e87)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68244", "url": "https://ubuntu.com/security/CVE-2026-68244", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/gem: Do not leak siblings[] on proto context error After a successful BALANCE/PARALLEL_SUBMIT extension on context creation, error during processing of next user extension leaks the siblings[] array. Fix that. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit aa65e0a4b51b3b54b53e4142aaa2d997aa1061ff)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68248", "url": "https://ubuntu.com/security/CVE-2026-68248", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915: Return NULL on error in active_instance Avoid returning &node->base when node is NULL due to OOM during GFP_ATOMIC allocation. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 6029bc064f0b1bac184203a50fbaaf070fa18832)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68249", "url": "https://ubuntu.com/security/CVE-2026-68249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma5.0: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit 8d144a0eb09537055841af48c9e7c2d4cd48e84d)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68250", "url": "https://ubuntu.com/security/CVE-2026-68250", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma5.2: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit ae658afc7f47f6147371ec42cc6b1a793dfdb5af)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68251", "url": "https://ubuntu.com/security/CVE-2026-68251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma6.0: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit c17a508a7d652da3728f8bbc481bfffe96d65a87)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68255", "url": "https://ubuntu.com/security/CVE-2026-68255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/virtio: bound EDID block reads to the response buffer virtio_get_edid_block() validates the read offset only against the device-supplied resp->size field, never against the fixed-size resp->edid array. The EDID block index is driven by the device-supplied extension count, so a malicious virtio-gpu backend can advertise a large size together with a high block count and read far past the array into adjacent kernel memory, which is then surfaced in the parsed EDID (an out-of-bounds read / info leak). Also reject any read whose end exceeds the size of the edid array. Conforming EDID responses stay within the array and are unaffected.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68256", "url": "https://ubuntu.com/security/CVE-2026-68256", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: detect_link_and_local_sink: DP alt mode timeout path leaks prev_sink reference prev_sink is unconditionally retained via dc_sink_retain at function entry, but the DP alt mode timeout path inside SIGNAL_TYPE_DISPLAY_PORT returns false without releasing prev_sink. All other return paths in the function correctly call dc_sink_release(prev_sink), making this the only missing cleanup. (cherry picked from commit 45510cf662dcf46b5d8926d454f338809f107b9d)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68259", "url": "https://ubuntu.com/security/CVE-2026-68259", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Check bounds in allocate_event_notification_slot The valid event ids go from 0 to KFD_SIGNAL_EVENT_LIMIT allocate_event_notification_slot has an option to specify an event id to allocate at, used by CRIU. We weren't checking the bounds on that value. Check them. v2: Lower bounds check is unecessary because of idr_alloc already rejecting negative numbers. Upper bounds check should be KFD_SIGNAL_EVENT_LIMIT since the signal mode mappings might not yet exist (cherry picked from commit 6853f1f6cbbeb3f53ebbbd7286536aeb2c5d5f50)", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68269", "url": "https://ubuntu.com/security/CVE-2026-68269", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/gem: Add missing nospec on parallel submit slot Add missing Spectre mitigation for userspace controlled parallel submission slot. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 15b9353deff3cf72331c387780de3cf9c316b643)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68271", "url": "https://ubuntu.com/security/CVE-2026-68271", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/nouveau: fix reversed error cleanup order in ucopy functions nouveau_uvmm_vm_bind_ucopy() and nouveau_exec_ucopy() place their error cleanup labels in allocation order rather than reverse allocation order. On a u_memcpya() failure for in_sync.s, the goto to err_free_ops (or err_free_pushs) frees the first allocation and then falls through to err_free_ins, which calls u_free() on args->in_sync.s. Since args->in_sync.s still holds the ERR_PTR returned by the failed u_memcpya(), and ERR_PTR values are not caught by ZERO_OR_NULL_PTR(), kvfree() proceeds to dereference it, which can result in a kernel oops. A failure for out_sync.s instead jumps to err_free_ins and skips freeing the first allocation, leading to a memory leak. Fix by swapping the cleanup label order so resources are freed in the correct reverse allocation sequence.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68272", "url": "https://ubuntu.com/security/CVE-2026-68272", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: validate CP_GFX_SHADOW chunk size in CS pass1 Add a minimum-length check for the AMDGPU_CHUNK_ID_CP_GFX_SHADOW chunk in amdgpu_cs_pass1(), matching the gate already present for the IB, FENCE and BO_HANDLES chunk types. The CP_GFX_SHADOW case previously shared a bare break with the dependency and syncobj chunk types, which do not dereference a fixed-size struct. When userspace submits this chunk with length_dw == 0, vmemdup_array_user() is called with size 0 and returns ZERO_SIZE_PTR, which passes the IS_ERR() check. amdgpu_cs_p2_shadow() then dereferences chunk->kdata as a struct drm_amdgpu_cs_chunk_cp_gfx_shadow (reading shadow->flags), faulting on the ZERO_SIZE_PTR and causing a NULL-pointer dereference. This is reachable by an unprivileged process in the render group. Reject undersized chunks with -EINVAL during pass1 so the bad submission is rejected before pass2 ever dereferences the data. (cherry picked from commit 7f61b2eef7415eccdb40850aca0de94211948657)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68277", "url": "https://ubuntu.com/security/CVE-2026-68277", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/dp/mst: fix OOB reads on 2-byte fields in sideband reply parsers Three sideband reply parsers read 16-bit fields as: val = (raw->msg[idx] << 8) | (raw->msg[idx+1]); and check bounds only after the fact. When idx == raw->curlen, raw->msg[idx+1] reads one byte past the received message data into the following struct fields (curchunk_len, curchunk_idx, curlen). Affected functions: - drm_dp_sideband_parse_enum_path_resources_ack() full_payload_bw_number and avail_payload_bw_number fields - drm_dp_sideband_parse_allocate_payload_ack() allocated_pbn field - drm_dp_sideband_parse_query_payload_ack() allocated_pbn field Fix by using a single combined check (idx + 2 > curlen) before each 2-byte read. Since the check is strictly tighter than idx > curlen, no separate step is needed. [added fixes tag]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68278", "url": "https://ubuntu.com/security/CVE-2026-68278", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/dp/mst: fix buffer overflows in sideband chunk accumulation drm_dp_sideband_append_payload() has three related bugs when processing device-provided sideband reply data: 1. Zero-length curchunk_len underflow: msg_len is a 6-bit field taken directly from the DP sideband header. If a device sends msg_len=0, curchunk_len is set to zero. The condition (curchunk_idx >= curchunk_len) is immediately true, and curchunk_len-1 wraps to 255 (u8 underflow). drm_dp_msg_data_crc4() reads 255 bytes from chunk[48], then memcpy() writes 255 bytes into msg[], both far out of bounds. 2. chunk[48] overflow: curchunk_len can reach 63 (6-bit field). chunk[] is only 48 bytes. Multi-iteration payload assembly appends 16-byte blocks until curchunk_idx reaches curchunk_len, writing up to 15 bytes past the end of chunk[] into msg[]. 3. msg[256] overflow: each chunk contributes (curchunk_len-1) bytes to msg[]. No check ensures curlen + (curchunk_len-1) stays within msg[256], so the memcpy can spill into adjacent struct fields. All three are reachable from any DP MST device that can forge sideband reply messages on a physical connection.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68279", "url": "https://ubuntu.com/security/CVE-2026-68279", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/dp/mst: fix OOB reads in remote DPCD/I2C sideband reply parsers drm_dp_sideband_parse_remote_dpcd_read() reads num_bytes from the raw message and then unconditionally does: memcpy(bytes, &raw->msg[idx], num_bytes); without checking that idx + num_bytes <= raw->curlen. raw->msg[] is 256 bytes; if a malicious or misbehaving MST hub sets num_bytes larger than the remaining payload, the memcpy reads past the received data into whatever follows in raw->msg[]. drm_dp_sideband_parse_remote_i2c_read_ack() has the same flaw (noted with a /* TODO check */ comment since the code was introduced). Fix both functions by using a single combined check (idx + num_bytes > curlen) before each memcpy. Since num_bytes is u8, it is always >= 0, so this strictly subsumes the simpler idx > curlen form and no separate step is needed. [added missing fixes tag]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68280", "url": "https://ubuntu.com/security/CVE-2026-68280", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/bridge: cdns-dsi: Replace deprecated UNIVERSAL_DEV_PM_OPS() The deprecated UNIVERSAL_DEV_PM_OPS() macro uses the provided callbacks for both runtime PM and system sleep. This causes the DSI clocks to be disabled twice: once during runtime suspend and again during system suspend, resulting in a WARN message from the clock framework when attempting to disable already-disabled clocks. [ 84.384540] clk:231:5 already disabled [ 84.388314] WARNING: CPU: 2 PID: 531 at /drivers/clk/clk.c:1181 clk_core_disable+0xa4/0xac ... [ 84.579183] Call trace: [ 84.581624] clk_core_disable+0xa4/0xac [ 84.585457] clk_disable+0x30/0x4c [ 84.588857] cdns_dsi_suspend+0x20/0x58 [cdns_dsi] [ 84.593651] pm_generic_suspend+0x2c/0x44 [ 84.597661] ti_sci_pd_suspend+0xbc/0x15c [ 84.601670] dpm_run_callback+0x8c/0x14c [ 84.605588] __device_suspend+0x1a0/0x56c [ 84.609594] dpm_suspend+0x17c/0x21c [ 84.613165] dpm_suspend_start+0xa0/0xa8 [ 84.617083] suspend_devices_and_enter+0x12c/0x634 [ 84.621872] pm_suspend+0x1fc/0x368 To address this issue, replace UNIVERSAL_DEV_PM_OPS() with RUNTIME_PM_OPS(). Bridge and panel drivers should only deal with runtime PM, as the DRM framework manages system-wide power transitions through the bridge enable() and disable() hooks.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68284", "url": "https://ubuntu.com/security/CVE-2026-68284", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Fix cork use-after-free in tcp_bpf_sendmsg() tcp_bpf_sendmsg() keeps msg_tx across sk_stream_wait_memory(), which drops and reacquires the socket lock. Its error path tries to decide whether msg_tx names the local temporary message by comparing it with the current value of psock->cork. This comparison is unsafe when two threads send on the same socket: Thread A Thread B msg_tx = psock->cork sk_msg_alloc() fails sk_stream_wait_memory() releases the socket lock acquires the socket lock completes the cork psock->cork = NULL frees the cork reacquires the socket lock msg_tx != psock->cork sk_msg_free(msg_tx) The stale cork is therefore mistaken for the local temporary message and freed again. KASAN reported: BUG: KASAN: slab-use-after-free in sk_msg_free+0x49/0x50 Read of size 4 at addr ffff88810c908800 by task poc/90 Call Trace: sk_msg_free+0x49/0x50 tcp_bpf_sendmsg+0x14f5/0x1cc0 __sys_sendto+0x32c/0x3a0 __x64_sys_sendto+0xdb/0x1b0 Allocated by task 89: __kasan_kmalloc+0x8f/0xa0 tcp_bpf_sendmsg+0x16b3/0x1cc0 Freed by task 91: __kasan_slab_free+0x43/0x70 kfree+0x131/0x3c0 tcp_bpf_sendmsg+0xec3/0x1cc0 msg_tx can only name the stack-local tmp or the shared cork. Check for tmp directly so a changed psock->cork cannot turn a shared message into an apparent local one.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68294", "url": "https://ubuntu.com/security/CVE-2026-68294", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qrtr: restrict socket creation to the initial network namespace QRTR keeps its entire port and node state in module-global variables that are not partitioned per network namespace: qrtr_local_nid is a single global node id (always 1) and qrtr_ports is a single global xarray. qrtr_port_lookup() and qrtr_local_enqueue() operate on that global state with no network-namespace check, and qrtr_create() places no restriction on the namespace a socket is created in. As a result an unprivileged process that creates an AF_QIPCRTR socket in a separate network namespace, e.g. via unshare(CLONE_NEWUSER | CLONE_NEWNET), can send QRTR datagrams - including control-plane messages such as QRTR_TYPE_NEW_SERVER - to QRTR sockets owned by another namespace, and vice versa. The receiving socket sees such a message as coming from node id 1, indistinguishable from a legitimate local client, breaking the isolation that network namespaces are expected to provide. QRTR is a transport to global hardware endpoints (the modem and other remote processors) and has no per-namespace semantics; its in-kernel name service already creates its socket in init_net only. Confine the socket family to the initial network namespace, as other non-namespace-aware socket families do (see llc_ui_create() and the ieee802154 socket code).", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68297", "url": "https://ubuntu.com/security/CVE-2026-68297", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix u16 MTU truncation in media and bearer MTU validation Both TIPC_NL_MEDIA_SET and TIPC_NL_BEARER_SET accept user-supplied MTU values but only enforce a minimum bound, not a maximum. When a user sets the MTU to a value exceeding U16_MAX (65535), it passes validation but is silently truncated when assigned to u16 fields l->mtu and l->advertised_mtu in tipc_link_create(). Values like 65536 (0x10000) truncate to 0, causing a division by zero in tipc_link_set_queue_limits() which computes TIPC_MAX_PUBL / (l->mtu / ITEM_SIZE). Other overflowing values (e.g. 65537-131071) produce small incorrect MTU values, resulting in link malfunction behaviors. Crash stack (triggered as unprivileged user via user namespace): tipc_link_set_queue_limits net/tipc/link.c:2531 tipc_link_create net/tipc/link.c:520 tipc_node_check_dest net/tipc/node.c:1279 tipc_disc_rcv net/tipc/discover.c:252 tipc_rcv net/tipc/node.c:2129 tipc_udp_recv net/tipc/udp_media.c:392 Two independent paths lack the upper bound check: 1. tipc_udp_mtu_bad() -- called from __tipc_nl_media_set() (MEDIA_SET) 2. inline check in __tipc_nl_bearer_set() at bearer.c:1160 (BEARER_SET) Fix both by rejecting MTU values above U16_MAX.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68299", "url": "https://ubuntu.com/security/CVE-2026-68299", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vmxnet3: fix BUG_ON in vmxnet3_get_hdr_len() for Geneve packets vmxnet3_get_hdr_len() assumes gdesc->rcd.v4/v6/tcp always describe the outer header, but for a Geneve-encapsulated packet the device can set them based on the inner header instead, signalled by the VMXNET3_RCD_HDR_INNER_SHIFT bit in the completion descriptor. Since the function never skips the outer encapsulation, this mismatch triggers: - BUG_ON(hdr.ipv4->protocol != IPPROTO_TCP), because the outer protocol is UDP (Geneve), not TCP. - BUG_ON(hdr.eth->h_proto != ...), when the tunnel's outer and inner IP versions differ (e.g. outer IPv6/inner IPv4 or vice versa). Check VMXNET3_RCD_HDR_INNER_SHIFT up front and bail out, since the function cannot locate the inner header it would need to parse. Also convert the remaining BUG_ON()s in this function to return 0 defensively.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68300", "url": "https://ubuntu.com/security/CVE-2026-68300", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: auth: verify auth requirement when auth_chunk is NULL sctp_auth_chunk_verify() returns true unconditionally when chunk->auth_chunk is NULL, silently skipping authentication. This is incorrect when: 1. skb_clone() failed in the BH receive path, leaving auth_chunk NULL. In sctp_endpoint_bh_rcv() asoc is NULL for new connections, so the early sctp_auth_recv_cid() check cannot catch this. 2. No AUTH chunk precedes COOKIE-ECHO, so skb_clone() is never called and auth_chunk remains NULL. Fix by checking sctp_auth_recv_cid() when auth_chunk is NULL: if authentication is required, return false to drop the chunk; otherwise continue normally.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68301", "url": "https://ubuntu.com/security/CVE-2026-68301", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hsr: fix memory leak on slave unregistration by removing synced VLANs When an HSR master device is brought UP, it auto-adds VLAN 0 via vlan_vid0_add(), which propagates VID 0 to its slave devices (slave A and B). If a slave device is later unregistered while HSR is active (e.g., during netns cleanup or interface destruction), hsr_del_port() is called to detach the slave port from the HSR master. However, hsr_del_port() currently does not delete the VLAN IDs that were synced to the slave device by HSR. As a result, the slave device retains a refcount on VID 0 (and any other synced VLANs). When the slave device is destroyed, its vlan_info / vlan_vid_info structure remains allocated, leading to a memory leak. Fix this by calling vlan_vids_del_by_dev(port->dev, master->dev) in hsr_del_port() before unlinking slave A or slave B ports, matching the propagation logic in hsr_ndo_vlan_rx_add_vid() / hsr_ndo_vlan_rx_kill_vid() and the cleanup behavior in bonding and team drivers.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68302", "url": "https://ubuntu.com/security/CVE-2026-68302", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: amt: re-read skb header pointers after every pull Several AMT receive and transmit paths cache a pointer into the skb head (ip_hdr(), ipv6_hdr(), eth_hdr() or the AMT message header) and then call a helper that can reallocate that head before the cached pointer is used again. pskb_may_pull(), ip_mc_may_pull(), ipv6_mc_may_pull(), iptunnel_pull_header(), ip_mc_check_igmp() and ipv6_mc_check_mld() can all free the old head and move the data, so a pointer taken before the call dangles afterwards and the later access is a use-after-free of the freed head. The affected sites are: amt_rcv() caches ip_hdr() before amt_parse_type() pulls, then reads iph->saddr. amt_dev_xmit() caches ip_hdr()/ipv6_hdr() before ip_mc_check_igmp()/ ipv6_mc_check_mld() and pskb_may_pull(), then reads the group address. amt_multicast_data_handler() caches eth_hdr() before pskb_may_pull(), then writes the L2 header. amt_membership_query_handler() caches the AMT header, the outer and inner eth_hdr() and ip_hdr() before iptunnel_pull_header() and several pulls, then reads and writes them. amt_igmpv3_report_handler() and amt_mldv2_report_handler() cache ip_hdr()/ipv6_hdr() and the current group record and read the record count from the report header inside the record loop, across the *_mc_may_pull() calls. amt_update_handler() caches ip_hdr() and the AMT membership-update header before pskb_may_pull(), iptunnel_pull_header(), ip_mc_check_igmp() and the report handler, then reads iph->daddr and amtmu->nonce / amtmu->response_mac. Fix each site by either snapshotting the scalar that is used after the pull before the first pull runs, or re-deriving the header pointer from the skb after the last pull that can move the head. Values that are stable across the pull (source and group address, the response MAC and nonce, the record count, the outer source MAC) are snapshotted; pointers that are written through or read repeatedly are re-derived.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68304", "url": "https://ubuntu.com/security/CVE-2026-68304", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: fix 802.1X-SHA256 call trace warning Based on wpa_auth as 1x_256 mode, need to set up \"use_fwsup\" with BRCMF_PROFILE_FWSUP_1X. Or it will happen trace warning when call brcmf_cfg80211_set_pmk(). [ 4481.831101] ------------[ cut here ]------------ [ 4481.831102] WARNING: CPU: 1 PID: 2997 at drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c:7242 brcmf_cfg80211_set_pmk+0x77/0xd0 [brcmfmac] [...] [ 4481.831202] Call Trace: [ 4481.831204]   [ 4481.831205]  nl80211_set_pmk+0x183/0x250 [cfg80211] [ 4481.831233]  genl_family_rcv_msg_doit+0xea/0x150 [ 4481.831237]  genl_rcv_msg+0x104/0x240 [ 4481.831239]  ? cfg80211_probe_status+0x2c0/0x2c0 [cfg80211] [ 4481.831257]  ? genl_family_rcv_msg_doit+0x150/0x150 [ 4481.831259]  netlink_rcv_skb+0x4e/0x100 [ 4481.831261]  genl_rcv+0x24/0x40 [ 4481.831262]  netlink_unicast+0x236/0x380 [ 4481.831264]  netlink_sendmsg+0x250/0x4b0 [ 4481.831266]  sock_sendmsg+0x5c/0x70 [ 4481.831269]  ____sys_sendmsg+0x236/0x2b0 [ 4481.831271]  ? copy_msghdr_from_user+0x6d/0xa0 [ 4481.831272]  ___sys_sendmsg+0x86/0xd0 [ 4481.831274]  ? avc_has_perm+0x8c/0x1a0 [ 4481.831276]  ? preempt_count_add+0x6a/0xa0 [ 4481.831279]  ? sock_has_perm+0x82/0xa0 [ 4481.831280]  __sys_sendmsg+0x57/0xa0 [ 4481.831282]  do_syscall_64+0x38/0x90 [ 4481.831284]  entry_SYSCALL_64_after_hwframe+0x63/0xcd [ 4481.831286] RIP: 0033:0x7fd270d369b4", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68306", "url": "https://ubuntu.com/security/CVE-2026-68306", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: fix possible NULL-pointer deref in mt7996_mcu_sta_bfer_eht() mt76_connac_get_eht_phy_cap routine can theoretically return NULL so check cap pointer before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68308", "url": "https://ubuntu.com/security/CVE-2026-68308", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: check pointer returned by mt76_connac_get_he_phy_cap() mt76_connac_get_he_phy_cap routine can theoretically return NULL so check cap pointer before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68309", "url": "https://ubuntu.com/security/CVE-2026-68309", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: connac: fix possible NULL-pointer deref in mt76_connac_mcu_uni_bss_he_tlv() mt76_connac_get_he_phy_cap routine can theoretically return NULL so check cap pointer before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68310", "url": "https://ubuntu.com/security/CVE-2026-68310", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7915: guard HE capability lookups mt7915_mcu_bss_he_tlv() and mt7915_mcu_sta_bfer_tlv() both run after checking HE support, then dereference the HE PHY capability returned by mt76_connac_get_he_phy_cap(). That helper can return NULL when no capability entry matches the vif type. Fetch the capability before appending the TLV and skip the HE-specific setup when no matching capability is available.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68313", "url": "https://ubuntu.com/security/CVE-2026-68313", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix infinite loop in __tipc_nl_compat_dumpit cmd->dumpit callback can return a negative errno, causing an infinite loop due to the while(len) condition. As the loop never terminates, genl_mutex is never released, and other tasks waiting on it starve in D state. Check dumpit's return value, propagate it and jump to err_out on error.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64576", "url": "https://ubuntu.com/security/CVE-2026-64576", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nexthop: initialize extack in nh_res_bucket_migrate() nh_res_bucket_migrate() passes an uninitialized netlink_ext_ack to call_nexthop_res_bucket_notifiers(). When nh_notifier_res_bucket_info_init() fails (e.g. the kzalloc returns -ENOMEM), the error is propagated back before any notifier sets extack._msg, and the error path formats the stale pointer with pr_err_ratelimited(\"%s\\n\", extack._msg). With CONFIG_INIT_STACK_NONE this dereferences uninitialized stack memory: Oops: general protection fault, probably for non-canonical address ... KASAN: maybe wild-memory-access in range [...] RIP: 0010:string (lib/vsprintf.c:730) vsnprintf (lib/vsprintf.c:2945) _printk (kernel/printk/printk.c:2504) nh_res_bucket_migrate (net/ipv4/nexthop.c:1816) nh_res_table_upkeep (net/ipv4/nexthop.c:1866) rtm_new_nexthop (net/ipv4/nexthop.c:3323) rtnetlink_rcv_msg (net/core/rtnetlink.c:7076) netlink_sendmsg (net/netlink/af_netlink.c:1900) Kernel panic - not syncing: Fatal exception Zero-initialize extack so _msg is NULL on error paths that never set it.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-64577", "url": "https://ubuntu.com/security/CVE-2026-64577", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gtp: check skb_pull_data() return in gtp1u_send_echo_resp() gtp1u_send_echo_resp() ignores skb_pull_data()'s return value. Its caller gtp1u_udp_encap_recv() only guarantees 16 bytes (udphdr + gtp1_header), but the pull requests 20 (gtp1_header_long + udphdr). For a 16-19 byte echo request the pull fails and returns NULL without advancing skb->data; execution continues, and the following skb_push() plus the IP header pushed by iptunnel_xmit() move skb->data below skb->head, tripping skb_under_panic(). Fix it by dropping the packet when skb_pull_data() fails. skbuff: skb_under_panic: ... kernel BUG at net/core/skbuff.c:214! Call Trace: skb_push (net/core/skbuff.c:2648) iptunnel_xmit (net/ipv4/ip_tunnel_core.c:82) gtp_encap_recv (drivers/net/gtp.c:701 drivers/net/gtp.c:808 drivers/net/gtp.c:920) udp_queue_rcv_one_skb (net/ipv4/udp.c:2388) ... Kernel panic - not syncing: Fatal exception in interrupt", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68315", "url": "https://ubuntu.com/security/CVE-2026-68315", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: validate stream count in sctp_process_strreset_inreq() When processing a RESET_IN_REQUEST from a peer, sctp_process_strreset_inreq() derives the stream count from the parameter length but does not check whether the resulting RESET_OUT_REQUEST would exceed SCTP_MAX_CHUNK_LEN. The OUT request header (sctp_strreset_outreq, 16 bytes) is 8 bytes larger than the IN request header (sctp_strreset_inreq, 8 bytes). Generally, the IP payload is bounded to 65535 bytes, so the stream list cannot be large enough to trigger the overflow. However, on interfaces with MTU > 65535 (e.g., loopback with IPv6 jumbograms), a stream list that fits within the incoming IN parameter can cause a __u16 overflow in sctp_make_strreset_req() when computing the OUT request size, leading to an undersized skb allocation and a kernel BUG: net/core/skbuff.c:207 skb_panic net/core/skbuff.c:2625 skb_put net/sctp/sm_make_chunk.c:1535 sctp_addto_chunk net/sctp/sm_make_chunk.c:3695 sctp_make_strreset_req net/sctp/stream.c:655 sctp_process_strreset_inreq The local setsockopt path validates the generated reset request size. However, for an incoming-only reset, it accounts for the smaller IN request even though the peer must generate an OUT request with the same stream list. Such a request cannot be completed successfully by the peer. Reject peer IN requests whose corresponding OUT request would exceed SCTP_MAX_CHUNK_LEN. Also tighten the local check so it does not send an IN request that would require an oversized OUT request from the peer.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68317", "url": "https://ubuntu.com/security/CVE-2026-68317", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pds_core: fix auxiliary device add/del races Two paths add or delete the same slot (pf->vfs[vf_id].padev): a VF's pdsc_reset_done() and the PF's devlink enable_vnet/disable_vnet handler. They serialize on config_lock, but neither guards the slot under it correctly. add() registers and stores a new auxiliary device without first checking the slot, so a second add of an already-populated slot leaks the first device. del() makes that check outside config_lock, so two concurrent dels can both pass it; the first clears the slot, and the second dereferences a NULL pointer. Check and update the slot under config_lock in both paths.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68320", "url": "https://ubuntu.com/security/CVE-2026-68320", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: fix auth_chunk_list capacity check in sctp_auth_ep_add_chunkid sctp_auth_ep_add_chunkid() uses SCTP_NUM_CHUNK_TYPES (20) as the capacity limit for ep->auth_chunk_list, allowing it to hold up to 20 chunk entries (param_hdr.length up to 24). However, the copy destination asoc->c.auth_chunks in struct sctp_cookie is only SCTP_AUTH_MAX_CHUNKS (16) entries (20 bytes). When more than 16 chunks are added, sctp_association_init() memcpy overflows the destination by up to 4 bytes. Fix by using SCTP_AUTH_MAX_CHUNKS as the capacity limit, matching the destination capacity.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68324", "url": "https://ubuntu.com/security/CVE-2026-68324", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/intel: Fix out-of-bounds memset in dmar_latency_disable() dmar_latency_disable() intends to zero out only the single latency_statistic entry for the given type, but the memset size was computed as sizeof(*lstat) * DMAR_LATENCY_NUM, which clears the entire array starting from &lstat[type]. When type > 0, this writes beyond the end of the allocated array, corrupting adjacent memory. Fix by using sizeof(*lstat) to clear only the target entry.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68325", "url": "https://ubuntu.com/security/CVE-2026-68325", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Bound the early ACPI HID map The ivrs_acpihid command-line parser appends entries to a fixed four-element early_acpihid_map array. Unlike the sibling IOAPIC and HPET parsers, it does not reject a fifth entry before incrementing the map size. Check the capacity at the common found label before parsing the HID and UID or writing the entry.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68326", "url": "https://ubuntu.com/security/CVE-2026-68326", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: bound uAP association event IEs to the event buffer mwifiex_process_uap_event() handles EVENT_UAP_STA_ASSOC by exposing the (re)association request IEs that the firmware copies into the event: \tsinfo->assoc_req_ies = &event->data[len]; \tlen = (u8 *)sinfo->assoc_req_ies - (u8 *)&event->frame_control; \tsinfo->assoc_req_ies_len = le16_to_cpu(event->len) - (u16)len; event->len is supplied by the device firmware and is never validated, and the subtraction is unchecked. assoc_req_ies points into adapter->event_body[MAX_EVENT_SIZE], a fixed-size array embedded in the kmalloc()'d struct mwifiex_adapter. On the ap_11n_enabled path mwifiex_set_sta_ht_cap() walks these IEs with cfg80211_find_ie(), whose for_each_element() loop dereferences each element header. A firmware-reported event->len larger than the bytes actually received makes assoc_req_ies_len describe IEs that extend past event_body, so the walk reads out of the adapter slab object, a slab-out-of-bounds read (KASAN: slab-out-of-bounds in cfg80211_find_ie). An event->len smaller than the header instead makes the int subtraction negative, which wraps to a huge size_t when stored in assoc_req_ies_len. The same length is handed to cfg80211_new_sta(), so a more modest over-claim can also copy stale event_body bytes into the NL80211_CMD_NEW_STATION notification. A malicious or malfunctioning mwifiex device (USB/SDIO/PCIe) can deliver such an event while the interface is in AP/uAP mode. Validate event->len before use: reject a length that underflows the header or that would place the IEs outside the event_body[] buffer the event was copied into. event->len here is struct mwifiex_assoc_event.len, a payload field internal to this event, not the transport frame length, so it is validated in this handler rather than at the generic MWIFIEX_TYPE_EVENT receive path, which only sees the event cause and the transport frame length. The bound is against event_body[MAX_EVENT_SIZE] rather than the actually-received length because the transports store the event differently (USB and SDIO leave the 4-byte event header in event_skb, PCIe strips it via skb_pull), whereas event_body is the single fixed buffer all of them copy the event into. This is the event-path analogue of the receive-path bounds checks added in commit 119585281617 (\"wifi: mwifiex: Fix OOB and integer underflow when rx packets\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68327", "url": "https://ubuntu.com/security/CVE-2026-68327", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wan: wanxl: Only reset hardware after BAR mapping wanxl_pci_init_one() stores the freshly allocated card in driver data before the PLX BAR is mapped. Several early probe failures then unwind through wanxl_pci_remove_one(), including failure to allocate the coherent status area or to restore the DMA mask. wanxl_pci_remove_one() unconditionally calls wanxl_reset(), and wanxl_reset() dereferences card->plx. On those early failures card->plx is still NULL, so the error path can dereference a NULL MMIO pointer. Only issue the hardware reset once the BAR mapping exists. The remaining cleanup in wanxl_pci_remove_one() already checks whether later resources were allocated. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68328", "url": "https://ubuntu.com/security/CVE-2026-68328", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfp: Check resource mutex allocation nfp_cpp_resource_find() allocates a CPP mutex handle for the matching resource-table entry and then reports success. nfp_resource_try_acquire() immediately passes that handle to nfp_cpp_mutex_trylock(). However, nfp_cpp_mutex_alloc() returns NULL on failure. If that happens for a matching table entry, the resource lookup still returns success and the following trylock dereferences a NULL mutex pointer while opening the resource. nfp_resource_acquire() already treats failure to allocate the table mutex as -ENOMEM. Do the same for the resource mutex and fail the lookup before publishing the rest of the resource handle. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64574", "url": "https://ubuntu.com/security/CVE-2026-64574", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: tear down new links on vif update error path When ieee80211_vif_update_links() adds new links it allocates a link container for each and calls ieee80211_link_init() (which registers the per-link debugfs files with file->private_data pointing into the container) and ieee80211_link_setup(). If the subsequent drv_change_vif_links() fails, the error path restores the old pointers and jumps to 'free', which frees the new containers but never removes their debugfs entries or stops the links. The debugfs files survive with file->private_data dangling at the freed container, so a later open()+read() (e.g. link-1/txpower) dereferences freed memory in ieee80211_if_read_link(), a use-after-free. The removal path already dismantles links correctly via ieee80211_tear_down_links(), which removes each link's keys and debugfs entries and calls ieee80211_link_stop(); the add path on the error branch does not. Commit be1ba9ed221f (\"wifi: mac80211: avoid weird state in error path\") hardened this same error path for the link-removal case (new_links == 0) but left the newly-added links' teardown unaddressed. drv_change_vif_links() can fail at runtime on MLO drivers (internal allocation / queue / firmware command failures). Remove the new links' debugfs entries and stop them before freeing. BUG: KASAN: slab-use-after-free in ieee80211_if_read_link (net/mac80211/debugfs_netdev.c:127) Read of size 8 at addr ffff888011290000 by task exploit/145 Call Trace: ... ieee80211_if_read_link (net/mac80211/debugfs_netdev.c:127) short_proxy_read (fs/debugfs/file.c:373) vfs_read (fs/read_write.c:572) ksys_read (fs/read_write.c:716) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) ... Oops: general protection fault, probably for non-canonical address 0xdffffc000000000a RIP: 0010:ieee80211_if_read_link (net/mac80211/debugfs_netdev.c:127) Kernel panic - not syncing: Fatal exception", "cve_priority": "low", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68329", "url": "https://ubuntu.com/security/CVE-2026-68329", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Wait for completion instead of returning early in iommu_completion_wait() need_sync is a per-IOMMU flag shared by all domains and devices behind that IOMMU. It is set whenever a command is queued with sync == true and cleared when a completion-wait (CWAIT) command is queued. However, a cleared need_sync only means that a covering CWAIT has been queued, not that all previously queued commands have actually completed in hardware. iommu_completion_wait() read need_sync locklessly and returned early when it was false. This breaks the \"block until all previously queued commands have completed\" contract in a multi-CPU scenario: CPU2: queue inv-B => need_sync = true CPU1: queue CWAIT(N); need_sync = false; then wait_on_sem(N) CPU2: read need_sync == false => return 0 (no wait!) CPU2 returns without waiting for any sequence number even though its inv-B may not have completed yet (CWAIT(N), queued after inv-B, has not been signaled). CPU2 then proceeds to, for example, free page-table pages while the IOMMU can still walk stale translations, opening a use-after-free window. This is a logical race in the meaning of the flag, not a memory-visibility issue, so barriers alone do not help. Fix it without losing the optimization of avoiding redundant CWAIT commands: take iommu->lock before testing need_sync, and when it is false do not return early but wait for the last allocated sequence number (cmd_sem_val). Since need_sync == false implies no sync command was queued after the last CWAIT, that CWAIT is FIFO-ordered after every not-yet-completed command, so waiting for its sequence number guarantees all prior commands (possibly queued by another CPU) have completed. The common path with pending work is unchanged and no extra hardware command is issued.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68331", "url": "https://ubuntu.com/security/CVE-2026-68331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dpaa2-eth: put MAC endpoint device on disconnect fsl_mc_get_endpoint() returns the MAC endpoint device with a reference taken through device_find_child(). The Ethernet connect path stores that device in mac->mc_dev and keeps it for the lifetime of the connected MAC object. However, the disconnect path only disconnects and closes the MAC before freeing the dpaa2_mac object. It does not drop the endpoint device reference stored in mac->mc_dev, so every successful connect leaks that device reference when the MAC is later disconnected. Drop the endpoint device reference after closing the MAC and before freeing the dpaa2_mac object.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68333", "url": "https://ubuntu.com/security/CVE-2026-68333", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dpaa2-switch: put MAC endpoint device on disconnect fsl_mc_get_endpoint() returns the MAC endpoint device with a reference taken through device_find_child(). The switch port connect path stores that device in mac->mc_dev and keeps it for the lifetime of the connected MAC object. However, the disconnect path only closes the MAC and frees the dpaa2_mac object. It does not drop the endpoint device reference stored in mac->mc_dev, so every successful connect leaks that device reference when the MAC is later disconnected. Drop the endpoint device reference before freeing the dpaa2_mac object.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68335", "url": "https://ubuntu.com/security/CVE-2026-68335", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rds: drop incoming messages that cross network namespace boundaries rds_find_bound() looks up the destination socket using a global rhashtable keyed solely on (addr, port, scope_id). Network namespaces are not part of the key, so a sender in netns A can deliver an incoming message (inc) to a socket that lives in a different netns B. When this happens, inc->i_conn points to an rds_connection whose c_net is netns A, but the receiving rs lives in netns B. Once the child process that created netns A exits, cleanup_net() calls rds_loop_exit_net() -> rds_loop_kill_conns() -> rds_conn_destroy(), freeing that connection. If the survivor socket in netns B still holds the inc, any subsequent dereference of inc->i_conn is a use-after-free. There are two dangerous sites in rds_clear_recv_queue(): 1. inc->i_conn->c_lcong (offset 88 of freed rds_connection, size 200) read via rds_recv_rcvbuf_delta() -- confirmed by KASAN. 2. inc->i_conn->c_trans->inc_free(inc) (function pointer at offset 80) called via rds_inc_put() when the inc refcount reaches zero -- same race window, potential call-through-freed-object primitive. The bug is reachable from unprivileged user namespaces (CLONE_NEWUSER + CLONE_NEWNET), available since Linux 3.8. Fix this by rejecting the delivery in rds_recv_incoming() when the socket returned by rds_find_bound() belongs to a different network namespace than the connection that carried the message. Use the existing rds_conn_net() / sock_net() helpers and net_eq() for the comparison.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68336", "url": "https://ubuntu.com/security/CVE-2026-68336", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bonding: fix devconf_all NULL dereference when IPv6 is disabled When booting with the 'ipv6.disable=1' parameter, the devconf_all is never initialized because inet6_init() exits before addrconf_init() is called which initializes it. bond_send_validate(), however, will still call bond_ns_send_all() even ipv6 is indeed disabled. It will lead to NULL derefence of net->ipv6.devconf_all in ip6_pol_route(). BUG: kernel NULL pointer dereference, address: 000000000000000c [...] Workqueue: bond0 bond_arp_monitor [bonding] RIP: 0010:ip6_pol_route+0x69/0x480 [...] Call Trace: ? srso_return_thunk+0x5/0x5f ? __pfx_ip6_pol_route_output+0x10/0x10 fib6_rule_lookup+0xfe/0x260 ? wakeup_preempt+0x8a/0x90 ? srso_return_thunk+0x5/0x5f ? srso_return_thunk+0x5/0x5f ? sched_balance_rq+0x369/0x810 ip6_route_output_flags+0xd7/0x170 bond_ns_send_all+0xde/0x280 [bonding] bond_ab_arp_probe+0x296/0x320 [bonding] ? srso_return_thunk+0x5/0x5f bond_activebackup_arp_mon+0xb4/0x2c0 [bonding] process_one_work+0x196/0x370 worker_thread+0x1af/0x320 ? srso_return_thunk+0x5/0x5f ? __pfx_worker_thread+0x10/0x10 kthread+0xe3/0x120 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x199/0x260 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Fix this by adding ipv6_mod_enabled() condition check in the caller.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68338", "url": "https://ubuntu.com/security/CVE-2026-68338", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/packet: avoid fanout hook re-registration after unregister packet_set_ring() temporarily detaches a socket from packet delivery while reconfiguring its ring. It records the previous running state, clears po->num, unregisters the protocol hook when needed, drops po->bind_lock, and later restores po->num and re-registers the hook from the saved was_running value. That unlocked window can race with NETDEV_UNREGISTER. The notifier can observe the socket as not running, skip __unregister_prot_hook(), and invalidate the per-socket binding by setting po->ifindex to -1 and clearing po->prot_hook.dev. A one-member fanout group can still retain its shared fanout hook device pointer. When packet_set_ring() resumes, re-registering solely from the stale was_running state can re-add the fanout hook after the device has been unregistered. Treat po->ifindex == -1 as an invalidated binding after reacquiring po->bind_lock. This is distinct from ifindex 0, the normal unbound/wildcard state: ifindex -1 marks an existing device binding that was invalidated when the device was unregistered. Restore po->num as before, but do not re-register the hook if device unregister already detached the socket.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68339", "url": "https://ubuntu.com/security/CVE-2026-68339", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: validate Realtek vendor event length btusb_recv_event_realtek() reads the event code at data[0] and the Realtek subevent code at data[2] before deciding whether to consume a vendor event as a coredump. For example, the two-byte event ff 00 contains a complete vendor-event header declaring zero parameters. The old classifier still reads a nonexistent third byte and can misclassify the event as a coredump if the adjacent byte is 0x34. Require the HCI event header and first parameter to be present before inspecting the Realtek subevent code. Short events continue through the normal HCI receive path, which owns their protocol validation.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68340", "url": "https://ubuntu.com/security/CVE-2026-68340", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: occ: validate poll response sensor blocks The OCC poll response parser walks a counted list of sensor data blocks. It used the static backing-array capacity as the parse boundary, but a transport response makes only data_length bytes current and valid. A truncated response can therefore make the parser consume a block header or block extent outside the current response. Use data_length as the parent boundary, prove the fixed poll header and each current block header before reading them, and prove the complete block before advancing. Keep parsed sensor metadata local until the complete response has passed validation, then publish it. Propagate malformed-response errors before publishing the OCC as active.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68343", "url": "https://ubuntu.com/security/CVE-2026-68343", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: validate DFS referral PathConsumed parse_dfs_referrals() validates that the response contains the fixed referral entry array and, on for-next, the per-referral string offsets. However, the response also contains a PathConsumed value that is later used for DFS path parsing. If a malformed response provides a PathConsumed value larger than the search name, later DFS parsing can advance beyond the end of the path. Validate PathConsumed against the search name length before storing it in the parsed referral.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68348", "url": "https://ubuntu.com/security/CVE-2026-68348", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: tas2781: bound firmware description string parsing The TAS2781 firmware parser reads several variable-length description strings with strlen() before checking that the string terminator is present inside the firmware blob. A malformed firmware image without a NUL terminator can therefore make the parser walk past the end of the firmware buffer before the later size checks run. Add a small bounded string-length helper and use it for all description fields that are parsed from the firmware buffer. Keep the existing size checks for the fixed bytes that follow each string.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68450", "url": "https://ubuntu.com/security/CVE-2026-68450", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: free mapping node on duplicate reloc root insert __add_reloc_root() allocates a mapping_node before inserting it into rc->reloc_root_tree. If rb_simple_insert() finds an existing entry, it returns the existing rb_node and leaves the newly allocated node unlinked. The error path then returns -EEXIST without freeing the new node. Since the node was never inserted into reloc_root_tree, the later cleanup in put_reloc_control() cannot find it either. Free the newly allocated node before returning -EEXIST. The callers currently assert that -EEXIST should not happen, so this is a defensive cleanup for an unexpected duplicate insert path. If the path is ever reached, the local allocation should still be released.", "cve_priority": "medium", "cve_public_date": "2026-08-12 01:17:00 UTC" }, { "cve": "CVE-2026-68349", "url": "https://ubuntu.com/security/CVE-2026-68349", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: carl9170: fix buffer overflow in rx_stream failover path The failover continuation in carl9170_rx_stream() copies the full tlen from the second USB transfer instead of capping at rx_failover_missing bytes. When both transfers are near maximum size, the total exceeds the 65535-byte failover SKB, triggering skb_over_panic. Limit the copy size to the missing byte count. [Fix checkpatch CHECK:PARENTHESIS_ALIGNMENT]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68350", "url": "https://ubuntu.com/security/CVE-2026-68350", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: carl9170: fix OOB read from off-by-two in TX status handler The bounds check in carl9170_tx_process_status() uses `i > ((cmd->hdr.len / 2) + 1)` which is off by two, allowing 2 extra iterations past valid _tx_status entries when the firmware- controlled hdr.ext exceeds hdr.len/2. Fix by using the correct comparison `i >= (cmd->hdr.len / 2)`.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68351", "url": "https://ubuntu.com/security/CVE-2026-68351", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: carl9170: bound memcpy length in cmd callback to prevent OOB read When the firmware sends a command response with a length mismatch, carl9170_cmd_callback() logs the mismatch and calls carl9170_restart() but then falls through to memcpy(ar->readbuf, buffer + 4, len - 4). Since len comes from the firmware and can exceed ar->readlen, this copies more data than the readbuf was allocated for. Bound the memcpy to min(len - 4, ar->readlen) so that the response is still completed -- avoiding repeated restarts from queued garbage -- while preventing an overread past the response buffer.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68352", "url": "https://ubuntu.com/security/CVE-2026-68352", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: fix OOB read from firmware IE lengths in connect event The firmware-controlled beacon_ie_len, assoc_req_len, and assoc_resp_len fields in ath6kl_wmi_connect_event_rx() are not validated against the buffer length. Their sum (up to 765) can exceed the actual WMI event data, causing out-of-bounds reads during IE parsing and state corruption of wmi->is_wmm_enabled. Add a check that the total IE length fits within the buffer.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68353", "url": "https://ubuntu.com/security/CVE-2026-68353", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: fix OOB read from firmware num_msg in TX complete handler The firmware-controlled num_msg field (u8, 0-255) drives the loop in ath6kl_wmi_tx_complete_event_rx() without validation against the buffer length. This allows out-of-bounds reads of up to 1020 bytes past the WMI event buffer when the firmware sends an inflated num_msg. Add a check that the buffer is large enough to hold the fixed struct and the num_msg variable-length entries.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68354", "url": "https://ubuntu.com/security/CVE-2026-68354", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firewire: net: Fix fragmented datagram reassembly fwnet_frag_new() keeps a sorted list of received fragments for a partial datagram. When a new fragment is adjacent to an existing fragment, the code checks whether the new fragment also closes the gap to the next or previous list entry. Those neighbor lookups currently assume that the current fragment always has a real next or previous fragment. At a list edge, the next or previous entry is the list head, not a struct fwnet_fragment_info. The gap checks also compare against the old edge of the current fragment instead of the edge after adding the new fragment. As a result, a fragment that bridges two existing ranges may leave two adjacent ranges unmerged, so fwnet_pd_is_complete() can miss a complete datagram. Check for the list head before looking up the neighboring fragment, and compare the neighbor against the new fragment's far edge when deciding whether to merge all three ranges. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68355", "url": "https://ubuntu.com/security/CVE-2026-68355", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix potential buffer underflow in ath11k_hal_rx_msdu_list_get() When the first entry in msdu_details has a zero buffer address, the code accesses msdu_details[i - 1] with i == 0, causing a buffer underflow. Fix similarly to ath12k_wifi7_hal_rx_msdu_list_get() by adding a separate check for i == 0 before the main condition to prevent the out-of-bounds access. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68357", "url": "https://ubuntu.com/security/CVE-2026-68357", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: watchdog: pretimeout: Fix UAF in watchdog_unregister_governor() When a watchdog governor is unregistered, it updates existing watchdog devices that were using this governor by falling back to `default_gov`. If the governor being unregistered is currently set as `default_gov`, the `default_gov` is never cleared. This leads to 2 use-after-free issues: 1. New watchdog devices registered after this point will inherit the dangling `default_gov`. 2. Existing watchdog devices using the unregistered governor will have their `wdd->gov` reassigned to the dangling `default_gov`. Fix the UAF by clearing `default_gov` if it matches the governor being unregistered.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68359", "url": "https://ubuntu.com/security/CVE-2026-68359", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (nzxt-smart2) Stop device IO before calling hid_hw_stop Calling hid_hw_stop() does not stop the device IO. This results in a race condition between hid_input_report() and the point immediately following the execution of hid_device_io_start() within the driver probe function. If the probe operation fails after \"io start\" has been initiated, this race condition will result in a UAF vulnerability. Fix the problem by calling hid_device_io_stop() before calling hid_hw_stop().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68360", "url": "https://ubuntu.com/security/CVE-2026-68360", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (corsair-cpro) Stop device IO before calling hid_hw_stop Calling hid_hw_stop() does not stop the device IO. This results in a race condition between hid_input_report() and the point immediately following the execution of hid_device_io_start() within the driver probe function. If the probe operation fails after \"io start\" has been initiated, this race condition will result in a UAF vulnerability. Fix the problem by calling hid_device_io_stop() before calling hid_hw_stop().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68361", "url": "https://ubuntu.com/security/CVE-2026-68361", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (corsair-psu) Stop device IO before calling hid_hw_stop hid_hw_stop() does not stop the device IO. This results in a race condition between hid_input_report() and the point immediately following the execution of hid_device_io_start() within corsairpsu_probe(). If the probe operation fails after \"io start\" has been initiated, this race condition will result in a uaf vulnerability [1]. CPU0\t\t\t\tCPU1 ====\t\t\t\t==== corsairpsu_probe() hid_device_io_start() ... unlock driver_input_lock hid_hw_stop() kfree(hidraw)\t\t\t__hid_input_report() \t\t\t\t ... acquire driver_input_lock \t\t\t\t hid_report_raw_event() \t\t\t\t hidraw_report_event() \t\t\t\t ... access hidraw's list_lock // trigger uaf Consequently, when corsairpsu_probe() fails and hid_hw_stop() needs to be executed, the io_started flag is first cleared while holding the driver_input_lock to prevent potential race conditions involving input reports. [1] BUG: KASAN: slab-use-after-free in rt_spin_lock+0x83/0x400 kernel/locking/spinlock_rt.c:56 Call Trace: hidraw_report_event+0x5d/0x3a0 drivers/hid/hidraw.c:577 hid_report_raw_event+0x311/0x1730 drivers/hid/hid-core.c:2076 __hid_input_report drivers/hid/hid-core.c:2152 [inline] hid_input_report+0x44e/0x580 drivers/hid/hid-core.c:2174 hid_irq_in+0x47e/0x6d0 drivers/hid/usbhid/hid-core.c:286 __usb_hcd_giveback_urb+0x3b3/0x5e0 drivers/usb/core/hcd.c:1657 dummy_timer+0x8a9/0x47d0 drivers/usb/gadget/udc/dummy_hcd.c:2005 Allocated by task 10: hidraw_connect+0x57/0x430 drivers/hid/hidraw.c:606 hid_connect+0x5bf/0x19d0 drivers/hid/hid-core.c:2277 hid_hw_start+0xa8/0x120 drivers/hid/hid-core.c:2387 corsairpsu_probe+0xd9/0x3c0 drivers/hwmon/corsair-psu.c:782 Freed by task 10: hidraw_disconnect+0x4f/0x60 drivers/hid/hidraw.c:662 hid_disconnect drivers/hid/hid-core.c:2362 [inline] hid_hw_stop+0x101/0x1e0 drivers/hid/hid-core.c:2407 corsairpsu_probe+0x327/0x3c0 drivers/hwmon/corsair-psu.c:826 Fix the problem by calling hid_device_io_stop() before calling hid_hw_stop(). [groeck: Updated subject and description; call hid_device_io_stop() only if IO has been started]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68362", "url": "https://ubuntu.com/security/CVE-2026-68362", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix NULL pointer dereference in ath11k_hal_srng_access_begin In ATH11K_QMI_EVENT_FW_READY, ATH11K_FLAG_REGISTERED is set unconditionally even when ath11k_core_qmi_firmware_ready() fails. This leaves the driver in an inconsistent state where initialization is considered complete although the firmware ready handling did not finish successfully. During the subsequent SSR, the driver enters the restart path based on this incorrect state and dereferences uninitialized srng members, resulting in a NULL pointer dereference. Call trace: ath11k_hal_srng_access_begin+0xc/0x60 [ath11k] (P) ath11k_ce_cleanup_pipes+0x17c/0x180 [ath11k] ath11k_core_restart+0x40/0x168 [ath11k] Fix this by: - skipping firmware_ready if ATH11K_FLAG_REGISTERED is already set - setting ATH11K_FLAG_REGISTERED only when firmware_ready succeeds - setting ATH11K_FLAG_QMI_FAIL and aborting the FW_READY handling on error Tested-on: WCN6750 hw1.0 AHB WLAN.MSL.2.0.c2-00204-QCAMSLSWPLZ-1", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68363", "url": "https://ubuntu.com/security/CVE-2026-68363", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath9k: hif_usb: don't dereference hif_dev after re-arming firmware request ath9k_hif_request_firmware() re-arms an asynchronous firmware load via request_firmware_nowait(), passing hif_dev as the completion context, and then still dereferences hif_dev: \tdev_info(&hif_dev->udev->dev, \"ath9k_htc: Firmware %s requested\\n\", \t\t hif_dev->fw_name); The re-armed callback ath9k_hif_usb_firmware_cb() runs on the \"events\" workqueue and, when the firmware is missing, walks the retry chain into ath9k_hif_usb_firmware_fail() -> complete_all(&hif_dev->fw_done). That releases the wait_for_completion(&hif_dev->fw_done) in a concurrent ath9k_hif_usb_disconnect(), which then kfree()s hif_dev. The trailing dev_info() in the frame that re-armed the request can therefore read freed memory (hif_dev->udev, the first field of struct hif_device_usb): BUG: KASAN: slab-use-after-free in ath9k_hif_request_firmware Read of size 8 ... by task kworker/... ath9k_hif_request_firmware ath9k_hif_usb_firmware_cb drivers/net/wireless/ath/ath9k/hif_usb.c:1247 request_firmware_work_func Allocated by ...: ath9k_hif_usb_probe drivers/net/wireless/ath/ath9k/hif_usb.c Freed by ...: ath9k_hif_usb_disconnect -> kfree drivers/net/wireless/ath/ath9k/hif_usb.c The fw_done barrier only makes disconnect wait for the firmware chain to *terminate*; it does not protect the outer ath9k_hif_request_firmware() frame that re-armed the request and keeps touching hif_dev afterwards. Drop the post-request dev_info(): it is the only use of hif_dev after the async request is armed, and it is purely informational (the dev_err() on the failure path runs only when request_firmware_nowait() did not arm a callback, so hif_dev is still alive there). This was first reported by syzbot as a single, non-reproduced crash that was later auto-obsoleted, and was independently rediscovered by the reFuzz fuzzer, which produced a C reproducer (USB-gadget connect/disconnect of an ath9k_htc device whose firmware download fails). The vulnerable code is unchanged and still present in v7.1-rc6, where the slab-use-after-free reproduces under KASAN once the (sub-microsecond) race window is widened.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68365", "url": "https://ubuntu.com/security/CVE-2026-68365", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: io_edgeport: cap received transmit credits The interrupt-status packet reports transmit credits returned by the device. edge_interrupt_callback() adds the 16-bit value to txCredits without checking maxTxCredits. edge_write() uses txCredits minus the software FIFO count as the amount of data that fits. Since the FIFO is allocated with maxTxCredits bytes, txCredits exceeding maxTxCredits can cause OOB write in ring buffer. Cap accumulated credits at maxTxCredits. Conforming devices should never hit the cap.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68366", "url": "https://ubuntu.com/security/CVE-2026-68366", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: uvc: clamp SEND_RESPONSE length to the response buffer uvc_send_response() builds the UVC control response from a user-supplied struct uvc_request_data: \treq->length = min_t(unsigned int, uvc->event_length, data->length); \t... \tmemcpy(req->buf, data->data, req->length); req->length is clamped to uvc->event_length, which is taken from the host control request wLength (up to UVC_MAX_REQUEST_SIZE, 64), and to data->length, which comes from the UVCIOC_SEND_RESPONSE ioctl and is only checked for being negative. The source buffer data->data is only 60 bytes, so a response with uvc->event_length and data->length both greater than 60 makes memcpy() read past the end of data->data. Clamp req->length to sizeof(data->data) as well.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64583", "url": "https://ubuntu.com/security/CVE-2026-64583", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: udc: bdc: free IRQ and drain func_wake_notify before teardown The Broadcom BDC UDC driver registers its IRQ handler with devm_request_irq() in bdc_udc_init(), so the IRQ is released by devm only after bdc_remove() returns. devm releases resources in reverse LIFO order, but bdc_remove() runs bdc_udc_exit() and bdc_hw_exit() -> bdc_mem_free() manually before returning: bdc_udc_exit() tears down individual endpoint objects via bdc_free_ep(), while bdc_hw_exit() -> bdc_mem_free() frees and NULLs the DMA-coherent status-report ring (bdc->srr.sr_bds) and kfree()s bdc->bdc_ep_array. Both happen while the IRQ handler (bdc_udc_interrupt, requested with IRQF_SHARED) remains deliverable in the window up to the post-remove devm free_irq(). On receipt of a shared interrupt in that window, bdc_udc_interrupt() dereferences bdc->srr.sr_bds[bdc->srr.dqp_index] (NULL or freed DMA) and dispatches sr_handler callbacks that index into bdc_ep_array, causing a NULL-deref or use-after-free. The same window affects the delayed_work bdc->func_wake_notify, which is armed from the IRQ handler via bdc_sr_uspc() -> handle_link_state_change() -> schedule_delayed_work() and may self-rearm from its own callback bdc_func_wake_timer(). No cancel exists anywhere in the driver, so a queued work item that fires after bdc_remove() returns and the bdc structure is devm-freed dereferences freed memory. Replace devm_request_irq() with request_irq() and add an explicit free_irq(bdc->irq, bdc) in bdc_remove(). Clear BDC_GIE before free_irq() to stop the device from asserting interrupts, then free_irq() drains any in-flight handler, then cancel_delayed_work_sync() drains the func_wake_notify delayed work. This ordering ensures the IRQ handler and delayed work cannot interfere with the subsequent endpoint and DMA teardown in bdc_udc_exit() and bdc_hw_exit(). Wire the matching free_irq() into the bdc_udc_init() error path so the IRQ is released on probe failure, and route the bdc_init_ep() failure through err0 instead of returning directly. This issue was found by an in-house static analysis tool.", "cve_priority": "low", "cve_public_date": "2026-08-06 08:16:00 UTC" }, { "cve": "CVE-2026-68368", "url": "https://ubuntu.com/security/CVE-2026-68368", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_ncm: validate datagram bounds in ncm_unwrap_ntb() When unpacking host-supplied NTBs, ncm_unwrap_ntb() checks datagram length against frame_max but does not verify that the datagram fits within the declared block length. Additionally, when decoding multiple NTBs from a single socket buffer, subsequent block lengths are not checked against the actual remaining buffer data. With these checks missing, a malicious USB host can specify datagram offsets and lengths that point beyond the block, or supply secondary NTB headers declaring lengths larger than the buffer. skb_put_data() then copies adjacent kernel memory from skb_shared_info into the network skb. Fix this by verifying that sufficient buffer space remains for the NTB header before parsing, handling zero-length block declarations, ensuring that block lengths never exceed the remaining buffer space, and verifying that each datagram payload stays strictly within the block boundary.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68369", "url": "https://ubuntu.com/security/CVE-2026-68369", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: printer: fix infinite loop in printer_read() printer_read() uses the same variable for the requested copy size and the number of bytes actually copied to user space. copy_to_user() returns the number of bytes not copied, so when it fails to copy anything, the computed copied length becomes zero. In that case len, buf, current_rx_bytes and current_rx_buf are left unchanged. If RX data is available and the user buffer remains unwritable, the read loop can repeat indefinitely. Track the copied length separately and return -EFAULT, or the number of bytes already copied, if an iteration makes no progress.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64584", "url": "https://ubuntu.com/security/CVE-2026-64584", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_midi: cancel pending IN work before freeing the midi object The f_midi driver embeds a work item (midi->work) whose handler, f_midi_in_work(), dereferences the enclosing struct f_midi through container_of(). This work is armed from two sites: f_midi_complete(), on a normal IN-endpoint completion, and f_midi_in_trigger(), on an ALSA rawmidi output-stream start. Neither f_midi_disable() nor f_midi_unbind() cancels midi->work. f_midi_disable() only disables the endpoints and drains the in_req_fifo; it does not synchronize the work item, and the sound card is released asynchronously to the final free of the midi object. The midi object is reference-counted (midi->free_ref) and is freed in f_midi_free() only once both the usb_function reference and the rawmidi private_data reference have been dropped. In f_midi_unbind(), f_midi_disable() runs before the sound card is released, so while the USB endpoints are already disabled the rawmidi device is still usable by an open substream. A concurrent userspace write on such a substream can reach f_midi_in_trigger() and queue midi->work again after f_midi_disable() has returned. A work item armed this way may still be pending when the last reference drops and f_midi_free() proceeds to kfree(midi), letting f_midi_in_work() dereference the struct after it has been freed, a use-after-free. For this reason cancelling midi->work in f_midi_disable() would not be sufficient: the ALSA trigger path can rearm the work after disable() returns. Cancelling at the refcount-zero free site is the boundary after which neither arming source can survive, because by then both references that keep the midi object alive have been dropped: the USB endpoints are already disabled and the rawmidi device has been released. Fix this by calling cancel_work_sync(&midi->work) in the refcount-zero block of f_midi_free(), before the embedded work_struct is freed along with the rest of the structure. opts->lock is a sleeping mutex, so calling cancel_work_sync() under it is permitted, and the handler takes midi->transmit_lock rather than opts->lock, so no self-deadlock can occur while it waits for a running instance of the work to finish. This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-08-06 08:16:00 UTC" }, { "cve": "CVE-2026-68370", "url": "https://ubuntu.com/security/CVE-2026-68370", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: dummy_hcd: prevent fifo_req reuse during giveback dummy_hcd embeds a single shared usb_request (dum->fifo_req) that the \"emulated single-request FIFO\" fast-path in dummy_queue() reuses for small IN transfers: it copies the caller's request into it (req->req = *_req) and queues it, treating list_empty(&fifo_req.queue) as \"the slot is free\". The completion side (dummy_timer/transfer/nuke/dummy_dequeue) follows the standard pattern: list_del_init(&req->queue) unlinks the request, then the lock is dropped and usb_gadget_giveback_request() invokes req->complete(). But list_del_init() makes fifo_req.queue look empty *before* the completion callback returns, so a concurrent dummy_queue() on another CPU sees the slot as free, reuses fifo_req and runs req->req = *_req -- overwriting req->complete while dummy_timer is mid-calling it. The indirect call then jumps to a clobbered pointer, causing a general protection fault / page fault in dummy_timer (syzkaller extid faf3a6cf579fc65591ca). The clobbering write is an in-bounds memcpy on a live shared object, so KASAN cannot flag it. Add a fifo_req_busy bit covering the shared request's whole lifetime: set it in dummy_queue() when the FIFO fast-path takes fifo_req (making it the fast-path guard, replacing the list_empty(&fifo_req.queue) test), and clear it after the completion callback has returned, via a dummy_giveback() helper used at all four gadget-request giveback sites. The shared slot can no longer be reused until its completion callback has finished.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68373", "url": "https://ubuntu.com/security/CVE-2026-68373", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: at76c50x-usb: avoid length underflow in at76_guess_freq() at76_guess_freq() checks only that the received frame is at least a bare 802.11 header (24 bytes) before subtracting the fixed management-body offset: \tlen -= el_off; For both beacon and probe response frames, el_off is 36. If the frame is shorter than el_off, subtracting it causes the calculated IE length to wrap. The length is eventually passed to cfg80211_find_elem_match() as a very large unsigned value, so the element walk runs beyond the RX skb. This path is reached from at76_rx_tasklet() while scanning. If the device delivers a truncated beacon or probe response, the oversized IE length causes an out-of-bounds read during scanning. Skip the IE lookup if the frame does not reach the variable elements, before subtracting el_off.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64569", "url": "https://ubuntu.com/security/CVE-2026-64569", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mpls: fix NULL deref in mpls_valid_fib_dump_req() on CONFIG_INET=n On CONFIG_INET=n builds, mpls_valid_fib_dump_req() walks the parsed attribute table itself instead of calling ip_valid_fib_dump_req(). The RTA_OIF arm passes tb[RTA_OIF] to nla_get_u32() without checking it is present, so an RTM_GETROUTE dump for AF_MPLS with strict checking and no RTA_OIF hits a NULL dereference. RTM_GETROUTE is RTNL_KIND_GET, which rtnetlink_rcv_msg() permits without CAP_NET_ADMIN, so an unprivileged user can trigger it. 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:mpls_valid_fib_dump_req (net/mpls/af_mpls.c:2189) Call Trace: mpls_dump_routes (net/mpls/af_mpls.c:2236) netlink_dump (net/netlink/af_netlink.c:2331) __netlink_dump_start (net/netlink/af_netlink.c:2446) rtnetlink_rcv_msg (net/core/rtnetlink.c:7033) netlink_rcv_skb (net/netlink/af_netlink.c:2556) netlink_unicast (net/netlink/af_netlink.c:1345) netlink_sendmsg (net/netlink/af_netlink.c:1900) __sock_sendmsg (net/socket.c:790) ____sys_sendmsg (net/socket.c:2684) ___sys_sendmsg (net/socket.c:2738) __sys_sendmsg (net/socket.c:2770) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Skip unset attributes, as ip_valid_fib_dump_req() does.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68376", "url": "https://ubuntu.com/security/CVE-2026-68376", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: fix auth_hmacs array size in struct sctp_cookie The auth_hmacs array in struct sctp_cookie is supposed to store a complete SCTP_AUTH_HMAC_ALGO parameter, which consists of a struct sctp_paramhdr followed by N HMAC identifiers. However, the array size was calculated using an extra 2 bytes instead of sizeof(struct sctp_paramhdr), which is 4 bytes. When four HMAC identifiers are configured, the HMAC-ALGO parameter stored in the endpoint is larger than the auth_hmacs buffer in the cookie. As a result, sctp_association_init() copies beyond the end of auth_hmacs when initializing the association, corrupting the adjacent auth_chunks field. This can lead to an invalid HMAC identifier being accepted and later cause an out-of-bounds read in sctp_auth_get_hmac(). Fix the array size calculation by including the full SCTP parameter header size.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68377", "url": "https://ubuntu.com/security/CVE-2026-68377", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: act_tunnel_key: Defer dst_release to RCU callback Fix a race-condition use-after-free in tunnel_key_release_params(). The function releases the metadata_dst of the old params synchronously via dst_release() while deferring the params struct free with kfree_rcu(). A concurrent tunnel_key_act() reader on the datapath may still hold the old params pointer (under rcu_read_lock_bh) and proceed to call dst_clone(¶ms->tcft_enc_metadata->dst) after the writer's dst_release has already pushed the dst's rcuref to RCUREF_DEAD. zdi-disclosures@trendmicro.com produced a poc which i (and Victor) verified that KASAN reports: ================================================================== BUG: KASAN: slab-use-after-free in instrument_atomic_read_write include/linux/instrumented.h:112 BUG: KASAN: slab-use-after-free in atomic_sub_return_release include/linux/atomic/atomic-instrumented.h:326 BUG: KASAN: slab-use-after-free in __rcuref_put include/linux/rcuref.h:109 BUG: KASAN: slab-use-after-free in rcuref_put include/linux/rcuref.h:173 BUG: KASAN: slab-use-after-free in dst_release+0x5b/0x370 net/core/dst.c:168 Write of size 4 at addr ffff88806158de40 by task poc/9388 CPU: 0 UID: 0 PID: 9388 Comm: poc Tainted: G W 7.1.0-rc7 #7 PREEMPT(lazy) Tainted: [W]=WARN Hardware name: QEMU Ubuntu 25.10 PC v2 (i440FX + PIIX, + 10.1 machine, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:94 dump_stack_lvl+0x100/0x190 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 print_report+0x139/0x4ad mm/kasan/report.c:482 kasan_report+0xe4/0x1d0 mm/kasan/report.c:595 check_region_inline mm/kasan/generic.c:186 kasan_check_range+0x125/0x200 mm/kasan/generic.c:200 instrument_atomic_read_write include/linux/instrumented.h:112 atomic_sub_return_release include/linux/atomic/atomic-instrumented.h:326 __rcuref_put include/linux/rcuref.h:109 rcuref_put include/linux/rcuref.h:173 dst_release+0x5b/0x370 net/core/dst.c:168 refdst_drop include/net/dst.h:272 skb_dst_drop include/net/dst.h:284 skb_release_head_state+0x293/0x400 net/core/skbuff.c:1163 skb_release_all net/core/skbuff.c:1187 [..] Allocated by task 9391: kasan_save_stack+0x30/0x50 mm/kasan/common.c:57 kasan_save_track+0x14/0x30 mm/kasan/common.c:78 poison_kmalloc_redzone mm/kasan/common.c:398 __kasan_kmalloc+0x9a/0xb0 mm/kasan/common.c:415 kasan_kmalloc include/linux/kasan.h:263 __do_kmalloc_node mm/slub.c:5296 __kmalloc_noprof+0x2f1/0x830 mm/slub.c:5308 kmalloc_noprof include/linux/slab.h:954 kzalloc_noprof include/linux/slab.h:1188 offload_action_alloc+0x2f/0x130 net/core/flow_offload.c:35 tcf_action_offload_add_ex+0x1ba/0x880 net/sched/act_api.c:258 tcf_action_offload_add net/sched/act_api.c:293 tcf_action_init+0x66e/0xa20 net/sched/act_api.c:1547 tcf_action_add+0xf6/0x5d0 net/sched/act_api.c:2101 [..] Freed by task 9391: kasan_save_stack+0x30/0x50 mm/kasan/common.c:57 kasan_save_track+0x14/0x30 mm/kasan/common.c:78 kasan_save_free_info+0x3b/0x70 mm/kasan/generic.c:584 poison_slab_object mm/kasan/common.c:253 __kasan_slab_free+0x6b/0x90 mm/kasan/common.c:285 kasan_slab_free include/linux/kasan.h:235 slab_free_hook mm/slub.c:2689 slab_free mm/slub.c:6251 kfree+0x21f/0x6b0 mm/slub.c:6566 tcf_action_offload_add_ex+0x4ad/0x880 net/sched/act_api.c:284 tcf_action_offload_add net/sched/act_api.c:293 tcf_action_init+0x66e/0xa20 net/sched/act_api.c:1547 tcf_action_add+0xf6/0x5d0 net/sched/act_api.c:2101 The buggy address belongs to the object at ffff88806158de00 which belongs to the cache kmalloc-256 of size 256 The buggy address is located 64 bytes inside of freed 256-byte region [ffff88806158de00, ffff88806158df00) The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffff88806158d600 pfn:0x6158c head: order:1 mapcount:0 entire_map ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64578", "url": "https://ubuntu.com/security/CVE-2026-64578", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate compound request size before reading StructureSize2 When ksmbd validates a compound (chained) SMB2 request, ksmbd_smb2_check_message() reads pdu->StructureSize2 without first checking that the compound element is large enough to contain it. StructureSize2 is a 2-byte field at offset 64 (__SMB2_HEADER_STRUCTURE_SIZE) from the start of each element. The compound-walking logic only guarantees that a full 64-byte SMB2 header is present for the trailing element: when NextCommand is 0, len is reduced to the number of bytes remaining after next_smb2_rcv_hdr_off. A remote client can craft a compound request whose last element has exactly 64 bytes, so the 2-byte StructureSize2 read at offset 64 extends one byte past the receive buffer, producing a slab-out-of-bounds read. BUG: KASAN: slab-out-of-bounds in ksmbd_smb2_check_message (fs/smb/server/smb2misc.c:402) Read of size 2 at addr ffff888012ae31ac by task kworker/0:1/14 The buggy address is located 172 bytes inside of allocated 173-byte region Workqueue: ksmbd-io handle_ksmbd_work Call Trace: ... kasan_report (mm/kasan/report.c:595) ksmbd_smb2_check_message (fs/smb/server/smb2misc.c:402) handle_ksmbd_work (fs/smb/server/server.c:119) process_one_work (kernel/workqueue.c:3314) worker_thread (kernel/workqueue.c:3397) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) Reject any compound element that is too small to hold StructureSize2 before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68381", "url": "https://ubuntu.com/security/CVE-2026-68381", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: pin conn during async oplock break notification smb2_oplock_break_noti() and smb2_lease_break_noti() store a ksmbd_conn pointer in an async ksmbd_work and then queue that work on ksmbd-io. The work only increments conn->r_count, which prevents teardown from passing the pending-request wait after the increment, but it does not pin the struct ksmbd_conn object. If connection teardown races with an oplock break notification, the last conn reference can be dropped before the queued worker finishes. The worker then uses the freed conn in ksmbd_conn_write() and ksmbd_conn_r_count_dec(). Take a real conn reference when publishing the conn pointer to the async work item, and drop it after the notification work has decremented r_count. Apply the same lifetime rule to lease break notification, which uses the same work->conn pattern.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68386", "url": "https://ubuntu.com/security/CVE-2026-68386", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Reject unhashed UDP sockets on sockmap update UDP sockets get SOCK_RCU_FREE set when (auto-)bound. This means sk_is_refcounted(unbound) = true, while sk_is_refcounted(bound) = false. Because sockmap accepts unbound UDP sockets, a BPF program can increment a socket's refcount via lookup. If the socket is subsequently bound, the transition from unbound to bound causes bpf_sk_release() to skip the decrement of the refcount, causing a memory leak. unreferenced object 0xffff88810bc2eb40 (size 1984): comm \"test_progs\", pid 2451, jiffies 4295320596 hex dump (first 32 bytes): 7f 00 00 01 7f 00 00 01 d2 04 1b b7 04 d2 00 00 ................ 02 00 01 40 00 00 00 00 00 00 00 00 00 00 00 00 ...@............ backtrace (crc bdee079d): kmem_cache_alloc_noprof+0x557/0x660 sk_prot_alloc+0x69/0x240 sk_alloc+0x30/0x460 inet_create+0x2ce/0xf80 __sock_create+0x25b/0x5c0 __sys_socket+0x119/0x1d0 __x64_sys_socket+0x72/0xd0 do_syscall_64+0xa1/0x5f0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Instead of special-casing for refcounted sockets, reject unhashed UDP sockets during sockmap updates, as there is no benefit to supporting those. This effectively reverts the commit under Fixes, with two exceptions: 1. sock_map_sk_state_allowed() maintains a fall-through `return true`. 2. In the spirit of commit b8b8315e39ff (\"bpf, sockmap: Remove unhash handler for BPF sockmap usage\"), the proto::unhash BPF handler is not reintroduced. Historical note: this issue is related to commit 67312adc96b5 (\"bpf: reject unhashed sockets in bpf_sk_assign\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68388", "url": "https://ubuntu.com/security/CVE-2026-68388", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb/client: handle overlapping allocated ranges in fallocate smb3_simple_fallocate_range() can skip holes when an allocated range returned by the server starts before the current fallocate offset. The skipped hole is not zero-filled, but fallocate still returns success. A later write to that hole may therefore fail with ENOSPC. The function queries allocated ranges so that it can preserve existing contents and write zeroes only into holes. However, the server may return a range that starts before the current fallocate offset. For example, assume the fallocate request is [100, 400) and the only allocated range returned by the server is [0, 200): Request: [100, 400) Server range: [ 0, 200) allocated Correct: [100, 200) allocated data, skip [200, 400) hole, zero-fill Current: [100, 300) skipped [300, 400) zero-filled afterwards The current code adds the full server range length, 200, to the current offset 100 and moves to 300. As a result, the hole in [200, 300) is skipped without being zero-filled. Fix this by advancing only over the part of the allocated range that overlaps the current fallocate offset. Ignore ranges that end before the current offset and reject ranges whose end offset overflows. This also prevents a malformed range length from causing an out-of-bounds zero-buffer read.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68389", "url": "https://ubuntu.com/security/CVE-2026-68389", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_qca: Clear memdump state on invalid dump size qca_controller_memdump() allocates qca->qca_memdump before processing the first dump packet. For a sequence-zero packet it then disables IBS, marks memdump collection active, and reads the advertised dump size. If the controller reports a zero dump size, the error path frees the local qca_memdump object and returns without clearing qca->qca_memdump or undoing the collection state. A later memdump work item initializes its local pointer from qca->qca_memdump and skips allocation when that pointer is non-NULL, so it can operate on freed memory. The stale collection and IBS-disabled flags can also leave waiters or later transmit handling blocked behind an aborted dump. Clear the saved pointer and memdump state before returning from the invalid-size path, matching the cleanup used when hci_devcd_init() fails. A static analysis checker reported the stale memdump state, and manual source review confirmed the invalid-size failure path.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68391", "url": "https://ubuntu.com/security/CVE-2026-68391", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: mgmt: hold reference for hci_conn in mgmt_pending_cmds Dereferencing RCU-protected pointers outside critical sections is invalid and may lead to UAF. Use of hci_conn in hci_sync callbacks also needs to hold refcount to avoid UAF. Take appropriate locks for hci_conn lookups, and take refcount for hci_conn pointers stored in mgmt_pending_cmd so that the pointer stays valid. When accessing conn->state, ensure hdev->lock is held to avoid data race.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68392", "url": "https://ubuntu.com/security/CVE-2026-68392", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: mgmt: fix locking in unpair_device/disconnect_sync Dereferencing RCU-protected pointers outside critical sections is invalid and may lead to UAF. Take hdev->lock for hci_conn lookup and hci_abort_conn(). Don't use RCU to ensure the conn is fully initialized at this point.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64573", "url": "https://ubuntu.com/security/CVE-2026-64573", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: qca: fix NVM tag length underflow in TLV parser In the TLV_TYPE_NVM branch of qca_tlv_check_data() the tag loop bound is \"while (idx < length - sizeof(struct tlv_type_nvm))\". \"length\" is a signed int from the firmware TLV header and sizeof(struct tlv_type_nvm) is a size_t (12), so \"length\" is converted to size_t and any firmware-supplied \"length\" < 12 makes the subtraction wrap to a huge value. The loop body then reads a 12-byte struct tlv_type_nvm past the end of the short vmalloc'd firmware buffer (and the EDL_TAG_ID_* handlers can write past it). Rewrite the bound as \"idx + sizeof(struct tlv_type_nvm) <= length\"; both operands are non-negative, so it no longer underflows and a \"length\" too small for one record correctly skips the loop. BUG: KASAN: vmalloc-out-of-bounds in qca_download_firmware.isra.0 (drivers/bluetooth/btqca.c:421) Read of size 2 at addr ffffc900000e5004 by task kworker/u9:0/52 Workqueue: hci0 hci_power_on Call Trace: ... kasan_report (mm/kasan/report.c:595) qca_download_firmware.isra.0 (drivers/bluetooth/btqca.c:421 drivers/bluetooth/btqca.c:617) qca_uart_setup (drivers/bluetooth/btqca.c:948) qca_setup (drivers/bluetooth/hci_qca.c:2029) hci_uart_setup (drivers/bluetooth/hci_ldisc.c:438) hci_dev_open_sync (net/bluetooth/hci_sync.c:5227) hci_power_on (net/bluetooth/hci_core.c:920) process_one_work (kernel/workqueue.c:3322) worker_thread (kernel/workqueue.c:3486) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245)", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68449", "url": "https://ubuntu.com/security/CVE-2026-68449", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ata: sata_dwc_460ex: fix infinite loop in NCQ tag completion bit-scanning The hand-rolled bit-scanning loop in the NCQ completion path has an infinite loop bug. When tag_mask has only high bits set (e.g. 0x80000000), the inner while loop left-shifts tag_mask until it overflows to 0. At that point !(0 & 1) is always true and 0 <<= 1 stays 0, causing an infinite loop in hardirq context with a spinlock held. Replace the open-coded bit-scanning with __ffs() which correctly finds the least significant set bit and is bounded by the width of the argument.", "cve_priority": "medium", "cve_public_date": "2026-08-12 01:17:00 UTC" }, { "cve": "CVE-2026-68395", "url": "https://ubuntu.com/security/CVE-2026-68395", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ata: sata_dwc_460ex: enable SATA interrupts only after IRQ handler is registered sata_dwc_enable_interrupts() is called before platform_get_irq() and ata_host_activate(), leaving the SATA controller's interrupt mask enabled without a registered handler. If a later step fails (irq request, phy init, etc.) or if the controller asserts an interrupt during probe, the irq line may fire with no handler, causing a spurious interrupt storm. Move sata_dwc_enable_interrupts() after ata_host_activate() so that interrupts are only unmasked once the handler is registered and the core is fully initialized.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68397", "url": "https://ubuntu.com/security/CVE-2026-68397", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/iucv: take a reference on the socket found in afiucv_hs_rcv() afiucv_hs_rcv() looks up the destination socket under iucv_sk_list.lock, drops the lock, and then passes the socket to the afiucv_hs_callback_*() handlers without holding a reference. AF_IUCV sockets are not RCU-protected and are freed synchronously by iucv_sock_kill() -> sock_put(), so a concurrent close can free the socket in the window between read_unlock() and the handler, which then dereferences freed memory (for example sk->sk_data_ready() in afiucv_hs_callback_syn()). Take a reference with sock_hold() while the socket is still on the list and release it with sock_put() once the handler has run.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64572", "url": "https://ubuntu.com/security/CVE-2026-64572", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: fib: free fib_alias with kfree_rcu() on insert error path fib_table_insert() publishes new_fa into the leaf's fa_list with fib_insert_alias() before calling the fib entry notifiers. When a notifier fails, the error path removes new_fa with fib_remove_alias() (hlist_del_rcu) and frees it right away with kmem_cache_free(). fib_table_lookup() walks that list under rcu_read_lock() only, so a concurrent lookup that already reached new_fa keeps reading it after the free: BUG: KASAN: slab-use-after-free in fib_table_lookup (net/ipv4/fib_trie.c:1601) Read of size 1 at addr ffff88810676d4eb by task exploit/297 Call Trace: fib_table_lookup (net/ipv4/fib_trie.c:1601) ip_route_output_key_hash_rcu (net/ipv4/route.c:2814) ip_route_output_key_hash (net/ipv4/route.c:2705) __ip4_datagram_connect (net/ipv4/datagram.c:49) udp_connect (net/ipv4/udp.c:2144) __sys_connect (net/socket.c:2167) __x64_sys_connect (net/socket.c:2173) do_syscall_64 entry_SYSCALL_64_after_hwframe which belongs to the cache ip_fib_alias of size 56 Triggering the error path needs CAP_NET_ADMIN and a registered fib notifier that can reject a route; a netdevsim device whose IPv4 FIB resource is exhausted is enough. Free new_fa with alias_free_mem_rcu(), as fib_table_delete() already does for a fib_alias removed from the trie.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68398", "url": "https://ubuntu.com/security/CVE-2026-68398", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ppp: defer channel free to an RCU grace period to fix pppol2tp RX UAF pppol2tp_recv() runs in the L2TP UDP-encap softirq RX path: l2tp_udp_encap_recv() -> l2tp_recv_common() -> pppol2tp_recv() -> ppp_input(&po->chan) It runs under rcu_read_lock() holding only an l2tp_session reference and takes NO reference on the internal PPP channel (struct channel, chan->ppp) that ppp_input() dereferences. The pppox socket is SOCK_RCU_FREE, so 'po' and the embedded ppp_channel are RCU-safe. But the internal struct channel is a separate allocation that ppp_release_channel() frees with a plain kfree(): close(data socket) -> pppol2tp_release() -> pppox_unbind_sock() -> ppp_unregister_channel() -> ppp_release_channel() -> kfree(pch) For a channel that is bound (PPPIOCGCHAN) but not attached to a ppp unit (no PPPIOCCONNECT, pch->ppp == NULL) and not bridged, teardown skips both ppp_disconnect_channel()'s synchronize_net() and ppp_unbridge_channels()'s synchronize_rcu(), so the kfree() has no grace period. rcu_read_lock() in pppol2tp_recv() does not protect against a plain kfree(), so an in-flight ppp_input() on one CPU can dereference the channel just freed by close() on another CPU. The bug is reachable by an unprivileged user. Defer the channel free to an RCU callback via call_rcu() so the grace period fences any in-flight ppp_input(). The disconnect and unbridge teardown paths already fence with synchronize_net()/synchronize_rcu(); call_rcu() does the same here without stalling the close() path.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68402", "url": "https://ubuntu.com/security/CVE-2026-68402", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: bound element ID read when checking non-inheritance cfg80211_is_element_inherited() reads the first data octet of the candidate element (id = elem->data[0]) to look it up in an extension non-inheritance list. It does so after testing elem->id, but without verifying that the element actually has a data octet. A zero-length extension element (WLAN_EID_EXTENSION with length 0) therefore makes it read one octet past the end of the element. _ieee802_11_parse_elems_full() runs this check for every element of a frame once a non-inheritance context exists -- e.g. while parsing a per-STA profile of a Multi-Link element in a (re)association response, or a non-transmitted BSS profile -- so a crafted frame from an AP can trigger a one-octet slab-out-of-bounds read during element parsing: BUG: KASAN: slab-out-of-bounds in cfg80211_is_element_inherited Read of size 1 ... in net/wireless/scan.c Return early (treat the element as inherited) when an extension element carries no data, mirroring the existing handling of empty ID lists. The bug was found by fuzzing ieee802_11_parse_elems_full() under KASAN.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68403", "url": "https://ubuntu.com/security/CVE-2026-68403", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: initialize SDIO data work before cleanup brcmf_sdio_probe() stores the newly allocated bus in sdiodev->bus before allocating the ordered workqueue. If that allocation fails, the function jumps to fail and calls brcmf_sdio_remove(). brcmf_sdio_remove() unconditionally cancels bus->datawork. Initialize the work item before the first failure path that can reach brcmf_sdio_remove(), so the cleanup path always observes a valid work object. This issue was found by our static analysis tool and then confirmed by manual review of the probe error path and the remove-time work drain. The problem pattern is an early setup failure that reaches a cleanup helper which cancels an embedded work item before its initializer has run. A QEMU PoC forced alloc_ordered_workqueue() to fail at the same point in brcmf_sdio_probe(), before INIT_WORK(&bus->datawork) is reached. The resulting fail path calls brcmf_sdio_remove(), and DEBUG_OBJECTS reports the invalid work drain with brcmf_sdio_probe() and brcmf_sdio_remove() in the stack.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68405", "url": "https://ubuntu.com/security/CVE-2026-68405", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: free AP_VLAN bc_buf SKBs outside IRQ lock ieee80211_do_stop() removes AP_VLAN packets from the parent AP ps->bc_buf while holding ps->bc_buf.lock with IRQs disabled. It then calls ieee80211_free_txskb() before dropping the lock. ieee80211_free_txskb() is not just a passive SKB release. For SKBs with TX status state it can report a dropped frame through cfg80211/nl80211, and that path can reach netlink tap transmit. This is the same reason the pending queue cleanup in ieee80211_do_stop() already unlinks SKBs under the queue lock and frees them after IRQ state is restored. The buggy scenario involves two paths, with each column showing the order within that path: AP_VLAN management TX: AP_VLAN stop: 1. attach ACK-status state 1. clear the running state 2. queue a multicast SKB on 2. take ps->bc_buf.lock with IRQs parent ps->bc_buf disabled 3. unlink the AP_VLAN SKB 4. call ieee80211_free_txskb() Unlink matching AP_VLAN SKBs from ps->bc_buf under the existing lock, but move them to a local free queue. Drop the lock and restore IRQ state before calling ieee80211_free_txskb(). WARNING: kernel/softirq.c:430 at __local_bh_enable_ip", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68406", "url": "https://ubuntu.com/security/CVE-2026-68406", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: validate PMSR FTM preamble range PMSR FTM request parsing accepts preamble values outside the enumerated nl80211 preamble range. Reject out-of-range values before using them in the parser capability bit test using the policy. [drop unnecessary check]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68407", "url": "https://ubuntu.com/security/CVE-2026-68407", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: nl80211: free RNR data on MBSSID mismatch nl80211_parse_beacon() rejects EMA RNR data when there are fewer RNR entries than MBSSID entries. The rejected RNR allocation has not been attached to the beacon data yet, so free it before returning the error.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64571", "url": "https://ubuntu.com/security/CVE-2026-64571", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: p54: validate RX frame length in p54_rx_eeprom_readback() p54_rx_eeprom_readback() copies the requested EEPROM slice out of a device-supplied readback frame without checking that the skb actually holds that many bytes. Commit da1b9a55ff11 (\"wifi: p54: prevent buffer-overflow in p54_rx_eeprom_readback()\") closed the destination overflow by copying a fixed priv->eeprom_slice_size (and rejecting a mismatched advertised len), but the source side is still unbounded: nothing verifies the frame is long enough to supply that many bytes. A malicious USB device can send a short frame whose advertised len matches priv->eeprom_slice_size while the payload is truncated. The equality check passes and memcpy() reads past the end of the skb, leaking adjacent heap: BUG: KASAN: slab-out-of-bounds in p54_rx (drivers/net/wireless/intersil/p54/txrx.c:507) Read of size 1016 at addr ffff88800f077114 by task swapper/0/0 Call Trace: ... __asan_memcpy (mm/kasan/shadow.c:105) p54_rx (drivers/net/wireless/intersil/p54/txrx.c:507) p54u_rx_cb (drivers/net/wireless/intersil/p54/p54usb.c:163) __usb_hcd_giveback_urb (drivers/usb/core/hcd.c:1657) dummy_timer (drivers/usb/gadget/udc/dummy_hcd.c:2005) ... The buggy address belongs to the object at ffff88800f0770c0 which belongs to the cache skbuff_small_head of size 704 The buggy address is located 84 bytes inside of allocated 704-byte region [ffff88800f0770c0, ffff88800f077380) Check that the slice fits in the skb before copying.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68410", "url": "https://ubuntu.com/security/CVE-2026-68410", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: libertas: fix memory leak in helper_firmware_cb() helper_firmware_cb() neglects to free the single-stage firmware image after a successful async load, leading to a memory leak in the USB firmware-download path. Fix this memory leak by calling release_firmware() immediately after lbs_fw_loaded() returns. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in the current wireless tree. An x86_64 allyesconfig build showed no new warnings. As we do not have compatible Libertas USB hardware for exercising this firmware-download path, no runtime testing was able to be performed.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68411", "url": "https://ubuntu.com/security/CVE-2026-68411", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211_hwsim: clamp virtio RX length before skb_put hwsim_virtio_rx_work() passes the virtqueue used-ring length reported by the device straight to skb_put() on a fixed-size receive skb. A backend reporting a length larger than the skb tailroom drives skb_put() past the buffer end and hits skb_over_panic() -- a host-triggerable guest panic (denial of service). Clamp the length to the skb's available room before skb_put(). A conforming device never reports more than the posted buffer size, so valid frames are unaffected; a truncated over-report then fails the length/header checks in hwsim_virtio_handle_cmd() and is dropped, so truncating rather than dropping here cannot be turned into a parsing problem.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68413", "url": "https://ubuntu.com/security/CVE-2026-68413", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ipw2100: fix potential memory leak in ipw2100_pci_init_one() The memory allocated in the ipw2100_alloc_device() function is not freed in some of the error paths in ipw2100_pci_init_one(). Fix that by converting the direct return into a goto to the error path return. The error path when pci_enable_device() fails cannot jump to fail, since at this point priv is not set, so perform error handling inline.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68414", "url": "https://ubuntu.com/security/CVE-2026-68414", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: cancel sched scan results work on unregister cfg80211_sched_scan_results() can queue rdev->sched_scan_res_wk from a driver result notification while a scheduled scan request is present. The work callback recovers the containing cfg80211_registered_device and then locks the wiphy and walks the scheduled-scan request list. wiphy_unregister() already makes the wiphy unreachable and drains rdev work items before cfg80211_dev_free() can release the object, but it does not drain sched_scan_res_wk. A queued or running result work item can therefore cross the unregister/free boundary and access freed rdev state. The buggy scenario involves two paths, with each column showing the order within that path: scheduled-scan result path: unregister/free path: 1. cfg80211_sched_scan_results() 1. interface teardown stops and queues rdev->sched_scan_res_wk. removes the scheduled scan request. 2. cfg80211_wq starts the work 2. wiphy_unregister() drains other item and recovers rdev. rdev work items. 3. The worker locks rdev->wiphy 3. cfg80211_dev_free() destroys and and walks rdev state. frees rdev. Cancel sched_scan_res_wk in wiphy_unregister() alongside the other rdev work items. cancel_work_sync() removes a pending result notification and waits for an already running callback, so cfg80211_dev_free() cannot free rdev while this work item is still active. Validation reproduced this kernel report: BUG: KASAN: use-after-free in cfg80211_sched_scan_results_wk+0x4a6/0x530 Workqueue: cfg80211 cfg80211_sched_scan_results_wk [cfg80211] Read of size 8 Call trace: dump_stack_lvl+0x66/0xa0 print_report+0xce/0x630 cfg80211_sched_scan_results_wk+0x4a6/0x530 srso_alias_return_thunk+0x5/0xfbef5 __virt_addr_valid+0x224/0x430 kasan_report+0xac/0xe0 lockdep_hardirqs_on_prepare+0xea/0x1a0 process_one_work+0x8d0/0x18f0 (kernel/workqueue.c:3212) lock_is_held_type+0x8f/0x100 worker_thread+0x5ad/0xfd0 __kthread_parkme+0xc6/0x200 kthread+0x31e/0x410 trace_hardirqs_on+0x1a/0x170 ret_from_fork+0x576/0x810 __switch_to+0x57e/0xe20 __switch_to_asm+0x33/0x70 ret_from_fork_asm+0x1a/0x30", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64579", "url": "https://ubuntu.com/security/CVE-2026-64579", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: policy: preallocate inexact bins before xfrm_hash_rebuild reinsert xfrm_hash_rebuild()'s first loop preallocates the bins/chains the reinsert loop needs, so the reinsert (after hlist_del_rcu()) cannot allocate or fail. But its guard is inverted: it skips policies with prefixlen < threshold and preallocates for the rest. prefixlen < threshold is exactly when policy_hash_bysel() returns NULL and the reinsert takes the allocating xfrm_policy_inexact_insert() path. So the loop preallocates for the exact policies (which never allocate) and skips the inexact ones, whose bin/node is then allocated GFP_ATOMIC during reinsert. On failure the error path only WARN_ONCE()s and continues, leaving a poisoned bydst node; the next rebuild's hlist_del_rcu() dereferences LIST_POISON2 and takes a GPF. Reachable under memory pressure, deterministic via failslab. Invert the guard so preallocation covers exactly the reinserted policies; the reinsert then allocates nothing and cannot fail. Crash: Oops: general protection fault, probably for non-canonical address 0xfbd59c0000000024: 0000 [#1] SMP KASAN NOPTI KASAN: maybe wild-memory-access in range [0xdead...] ... Workqueue: events xfrm_hash_rebuild RIP: 0010:xfrm_hash_rebuild+0x5b3/0x1190 RAX: dead000000000122 (LIST_POISON2 + offset) ... Call Trace: hlist_del_rcu (include/linux/rculist.h:599) xfrm_hash_rebuild (net/xfrm/xfrm_policy.c:1365) process_one_work (kernel/workqueue.c:3322) worker_thread (kernel/workqueue.c:3486) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) ... Kernel panic - not syncing: Fatal exception in interrupt", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-64580", "url": "https://ubuntu.com/security/CVE-2026-64580", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm6: clear dst.dev on error to avoid double netdev_put in xfrm6_fill_dst() On the error path where in6_dev_get(dev) returns NULL, xfrm6_fill_dst() releases the device reference with netdev_put() but leaves xdst->u.dst.dev set. dst_destroy() later calls netdev_put(dst->dev) again, so the same net_device reference is released twice, underflowing its refcount (ref_tracker WARNING + \"unregister_netdevice: waiting for to become free\"). Clear xdst->u.dst.dev after the netdev_put(), the same way the XFRM device-offload paths xfrm_dev_state_add() and xfrm_dev_policy_add() in net/xfrm/xfrm_device.c NULL ->dev when releasing the reference on error. ref_tracker: reference already released. ref_tracker: allocated in: xfrm6_fill_dst (net/ipv6/xfrm6_policy.c:86) ... udpv6_sendmsg (net/ipv6/udp.c:1696) ... ref_tracker: freed in: xfrm6_fill_dst (net/ipv6/xfrm6_policy.c:90) ... WARNING: lib/ref_tracker.c:322 at ref_tracker_free+0x58b/0x780 dst_destroy (net/core/dst.c:115) rcu_core handle_softirqs ...", "cve_priority": "high", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68416", "url": "https://ubuntu.com/security/CVE-2026-68416", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: fix double free and WARN_ON in add_mtd_device() error paths When device_register() or mtd_nvmem_add() fails inside add_mtd_device() for a partition, the error handling triggers mtd_release() via put_device() or device_unregister(). mtd_release() calls release_mtd_partition() which frees the mtd_info structure. However, callers such as mtd_add_partition() and add_mtd_partitions() also call free_partition() in their error paths, resulting in a double free. Additionally, release_mtd_partition() hits WARN_ON(!list_empty( &mtd->part.node)) because the partition node is still linked in the parent's partitions list when the release callback fires from the add_mtd_device() error path. Fix this by overriding dev->type and dev->release before put_device() in the error paths, so that device_release() invokes a no-op function instead of mtd_release(). For the mtd_nvmem_add() failure case, device_unregister() is replaced with device_del() to separate the device removal from the final kobject reference drop, allowing the override to take effect before put_device() is called. The callers' error paths (list_del + free_partition) remain the sole owners of mtd_info lifetime on add_mtd_device() failure, which is the expected contract. The normal partition teardown path is not affected: del_mtd_device() goes through kref_put() -> mtd_device_release() -> device_unregister() with dev->type still set to &mtd_devtype, so mtd_release() -> release_mtd_partition() continues to work correctly for the regular removal case.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68417", "url": "https://ubuntu.com/security/CVE-2026-68417", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/siw: publish QP after initialization siw_create_qp() currently calls siw_qp_add() before the queues, CQ pointers, state, completion, and device list entry are ready. A QPN lookup can therefore reach a QP that is still being constructed. Move siw_qp_add() to the end of siw_create_qp(), after QP initialization and before adding the QP to the siw device list.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68419", "url": "https://ubuntu.com/security/CVE-2026-68419", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/irdma: Prevent rereg_mr for non-mem regions When a QP/CQ/SRQ is created, a two step process is used where the buffer is allocated in userspace and explicitly registered with the normal reg_mr mechanism prior to creating the actual QP/CQ/SRQ object. These special registrations are indicated via an ABI field so the driver knows that they do not have a valid mkey and to skip the actual CQP command submission. Since these are real MR objects from the core's perspective, it is possible for a user application to invoke rereg_mr on them and cause a real CQP op to be emitted with the zero-initialized mkey value of 0. Fix this by preventing rereg_mr on these special regions.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68444", "url": "https://ubuntu.com/security/CVE-2026-68444", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_ffa: Fix NULL dereference in ffa_partition_info_get() ffa_partition_info_get() passes uuid_str directly to uuid_parse() without a NULL check. When a caller passes NULL, uuid_parse() -> __uuid_parse() -> uuid_is_valid() dereferences the pointer, causing a kernel panic: | Unable to handle kernel NULL pointer dereference at virtual address | 0000000000000040 | pc : uuid_parse+0x40/0xac | lr : ffa_partition_info_get+0x1c/0x94 [arm_ffa] Add a NULL guard before uuid_parse() so a NULL argument returns -ENODEV instead of crashing. Callers are expected to always supply a valid partition UUID, so NULL is not a supported input.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68422", "url": "https://ubuntu.com/security/CVE-2026-68422", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix root leak if its reloc root is unexpected in merge_reloc_roots() If we have an unexpected reloc_root for our root, we jump to the out label but never drop the reference we obtained for root, resulting in a leak. Add a missing btrfs_put_root() call.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64567", "url": "https://ubuntu.com/security/CVE-2026-64567", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: reject free space cache with more entries than pages When loading a v1 free space cache, __load_free_space_cache() takes num_entries and num_bitmaps straight from the on-disk btrfs_free_space_header. That header is stored in the tree_root under a key with type 0, which the tree-checker has no case for, so neither count is validated before the load trusts it. The load loops num_entries times and maps the next page whenever the current one runs out, going through io_ctl_check_crc() -> io_ctl_map_page(), which does io_ctl->pages[io_ctl->index++]. But pages[] is allocated in io_ctl_init() from the cache inode's i_size, not from num_entries: \tnum_pages = DIV_ROUND_UP(i_size_read(inode), PAGE_SIZE); \tio_ctl->pages = kcalloc(num_pages, sizeof(struct page *), GFP_NOFS); So if num_entries claims more records than the pages can hold, io_ctl->index runs off the end of pages[]. The write side never hits this because io_ctl_add_entry() and io_ctl_add_bitmap() both stop once io_ctl->index >= io_ctl->num_pages; the read side just never had the same check. To trigger it, take a clean cache (num_entries = here), set num_entries in the header to 0x10000, and fix up the leaf checksum so it still passes the tree-checker. The cache inode has i_size = 65536, so num_pages is 16 and pages[] is a 16-pointer (kmalloc-128) array. The load now tries to read 65536 entries, io_ctl->index walks up to 16, and pages[16] is read past the array: BUG: KASAN: slab-out-of-bounds in io_ctl_check_crc (fs/btrfs/free-space-cache.c:420 fs/btrfs/free-space-cache.c:565) Read of size 8 at addr ffff88800c833a80 by task kworker/u8:3/58 io_ctl_check_crc (fs/btrfs/free-space-cache.c:420 fs/btrfs/free-space-cache.c:565) __load_free_space_cache (fs/btrfs/free-space-cache.c:655 fs/btrfs/free-space-cache.c:820) load_free_space_cache (fs/btrfs/free-space-cache.c:1017) caching_thread (fs/btrfs/block-group.c:880) btrfs_work_helper (fs/btrfs/async-thread.c:312) process_one_work worker_thread kthread ret_from_fork free-space-cache.c:420 is io_ctl_map_page(), inlined into io_ctl_check_crc() at line 565, which is why that is the frame KASAN names. The out-of-bounds slot is then treated as a struct page and handed to crc32c(), so the bad read turns into a GP fault. Add the missing check to io_ctl_check_crc(), which is where both the entry loop and the bitmap loop end up. When num_entries is too large the load now fails like any corrupt cache: __load_free_space_cache() drops it and rebuilds the free space from the extent tree, so a valid cache is never rejected.", "cve_priority": "high", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68425", "url": "https://ubuntu.com/security/CVE-2026-68425", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: IB/mad: Drop unmatched RMPP responses before reassembly Kernel-handled RMPP receive processing starts reassembly for active DATA responses before the response is matched to an outstanding send. The normal match happens later, after ib_process_rmpp_recv_wc() has either assembled a complete message or consumed the segment. That ordering lets an unsolicited response that routes to a kernel RMPP agent by the high TID bits allocate or extend RMPP receive state before the full TID and source address are checked against a real request. A reordered burst can therefore reach the receive-side insertion path even though the response would not match any send. For kernel-handled RMPP DATA responses, require the existing ib_find_send_mad() match before entering RMPP reassembly. The matcher already checks the full TID, management class and source address/GID against the agent wait, backlog and in-flight send lists. If there is no match, drop the response without creating RMPP state. This leaves the RMPP window behavior unchanged and only rejects responses that have no corresponding request.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64565", "url": "https://ubuntu.com/security/CVE-2026-64565", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: ims-pcu - fix heap-buffer-overflow in ims_pcu_process_data() The `ims_pcu_process_data()` processes incoming URB data byte by byte. However, it fails to check if the `read_pos` index exceeds IMS_PCU_BUF_SIZE. If a malicious USB device sends a packet larger than IMS_PCU_BUF_SIZE, `read_pos` will increment indefinitely. Moreover, since `read_pos` is located immediately after `read_buf`, the attacker can overwrite `read_pos` itself to arbitrarily control the index. This manipulated `read_pos` is subsequently used in `ims_pcu_handle_response()` to copy data into `cmd_buf`, leading to a heap buffer overflow. Specifically, an attacker can overwrite the `cmd_done.wait.head` located at offset 136 relative to `cmd_buf` in the `ims_pcu_handle_response()`. Consequently, when the driver calls `complete(&pcu->cmd_done)`, it triggers a control flow hijack by using the manipulated pointer. Fix this by adding a bounds check for `read_pos` before writing to `read_buf`. If the packet is too long, discard it, log a warning, and reset the parser state. [dtor: factor out resetting packet state, reset checksum as well]", "cve_priority": "medium", "cve_public_date": "2026-08-04 07:16:00 UTC" }, { "cve": "CVE-2026-68427", "url": "https://ubuntu.com/security/CVE-2026-68427", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpu: host1x: Fix use-after-free in host1x_bo_clear_cached_mappings __host1x_bo_unpin() drops the last reference to the mapping and frees it, so we can't dereference mapping afterwards. The cache itself outlives the mapping, so use the cache local variable instead.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-72146", "url": "https://ubuntu.com/security/CVE-2026-72146", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: sh: rz-dmac: Move interrupt request after everything is set up Once the interrupt is requested, the interrupt handler may run immediately. Since the IRQ handler can access channel->ch_base, which is initialized only after requesting the IRQ, this may lead to invalid memory access. Likewise, the IRQ thread may access uninitialized data (the ld_free, ld_queue, and ld_active lists), which may also lead to issues. Request the interrupts only after everything is set up. To keep the error path simpler, use dmam_alloc_coherent() instead of dma_alloc_coherent().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72124", "url": "https://ubuntu.com/security/CVE-2026-72124", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: isotp: serialize TX state transitions under so->rx_lock The TX state machine (so->tx.state) is driven from three contexts: sendmsg() claiming and progressing a transfer, the RX path consuming Flow Control/echo frames, and two hrtimers timing out a stalled transfer. Mixing a lock-free cmpxchg() claim in sendmsg() with hrtimer_cancel() calls made under so->rx_lock elsewhere left windows where a frame or timer callback could act on a state that had already moved on, corrupting an unrelated transfer. so->rx_lock now covers the full lifecycle of a TX claim: sendmsg() takes it to check so->tx.state is ISOTP_IDLE, switch it to ISOTP_SENDING, bump so->tx_gen and drain the previous transfer's timers - all as one critical section. isotp_rcv_fc()/isotp_rcv_cf() already run under this lock via isotp_rcv(), and isotp_rcv_echo() now takes it itself, so none of them can ever observe a transfer mid-claim. This also means a transfer can no longer be handed to sendmsg()'s cleanup paths (signal or send error) while another thread is concurrently claiming or finishing it, so those paths can cancel timers and reset the state unconditionally. isotp_release() claims the socket the same way, so a racing sendmsg() sees a consistent ISOTP_SHUTDOWN and skips arming its timer or sending. Only the hrtimer callbacks stay outside so->rx_lock, since they run under so->rx_lock's cancellation elsewhere and taking it themselves would deadlock. so->tx_gen lets them recognize whether the transfer they timed out is still the one currently active, so they don't report an error against a transfer that has since completed or been superseded.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72125", "url": "https://ubuntu.com/security/CVE-2026-72125", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: isotp: fix use-after-free race with concurrent NETDEV_UNREGISTER isotp_release() looked up the bound network device via dev_get_by_index() using the stored ifindex. During device unregistration the device is unlisted from the ifindex hash before the NETDEV_UNREGISTER notifier chain runs, so a concurrent isotp_release() could find no device, skip can_rx_unregister() entirely, and still proceed to free the socket. Since isotp_release() had already removed itself from the isotp notifier list at that point, isotp_notify() would never get a chance to clean up either, leaving a stale CAN filter that keeps pointing at the freed socket. Fix this the same way raw.c already does: hold a tracked reference to the bound net_device in the socket (so->dev/so->dev_tracker) from bind() onward instead of re-resolving it from the ifindex, and serialize bind()/release() with rtnl_lock() so that so->dev is always consistent with what the NETDEV_UNREGISTER notifier sees. so->dev stays valid regardless of ifindex-hash unlisting, and is only ever cleared by whichever of isotp_release()/isotp_notify() gets there first, so the filter is always removed exactly once. isotp_bind() now rejects a (re)bind with -EAGAIN while so->[tx|rx].state isn't ISOTP_IDLE yet, so a timer left running by a prior NETDEV_UNREGISTER can't act on a newly bound so->ifindex. Both checks share the same lock_sock() section, so there is no window in which a concurrent isotp_notify() clearing so->bound could be missed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72115", "url": "https://ubuntu.com/security/CVE-2026-72115", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: track a single source interface for ANYDEV timeout/throttle ops An ANYDEV rx op (ifindex == 0) with an active RX timeout and/or throttle timer has no defined semantics when matching frames arrive from several interfaces: bcm_rx_handler() can run concurrently for the same op on different CPUs, racing hrtimer_cancel()/ bcm_rx_starttimer() against bcm_rx_timeout_handler() and causing spurious RX_TIMEOUT notifications and last_frames corruption. The same concurrency lets throttled multiplex frames from different interfaces clobber the single rx_ifindex/rx_stamp fields shared by the op. Add op->if_detected to track the first interface that delivers a matching frame while a timeout/throttle timer is configured, and reject frames from any other interface for that op. The claim is decided in bcm_rx_handler() before hrtimer_cancel() touches op->timer, so a rejected frame can never disturb the claimed interface's watchdog. RTR-mode ops are excluded via RX_RTR_FRAME, independent of kt_ival1/kt_ival2, since those may briefly hold a stale value from an earlier non-RTR configuration. The claim is released in bcm_notify() on NETDEV_UNREGISTER and in bcm_rx_setup() when SETTIMER reconfigures the timer values. A (re-)claim is only possible on CAN devices in NETREG_REGISTERED dev->reg_state to cover the release in bcm_notify() where reg_state becomes NETREG_UNREGISTERING until synchronize_net().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72117", "url": "https://ubuntu.com/security/CVE-2026-72117", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: fix data race on rx_stamp/rx_ifindex in bcm_rx_handler() For an rx op subscribed on all interfaces (ifindex == 0), the same op is registered once in the shared per-netns wildcard filter list, so bcm_rx_handler() can run concurrently on different CPUs for frames arriving on different net devices. op->rx_stamp and op->rx_ifindex were written before bcm_rx_update_lock was taken, allowing concurrent writers to race each other - including a torn store of the 64-bit rx_stamp on 32-bit platforms. Beyond a torn store bcm_send_to_user() must report the timestamp/ifindex of the very same frame whose content it is delivering. So the assignment is placed in the same unbroken bcm_rx_update_lock section as the content comparison. As a side effect, the RTR-request frame feature (which never reach bcm_send_to_user()) no longer updates rx_stamp/rx_ifindex, since only the notification path needs them.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72116", "url": "https://ubuntu.com/security/CVE-2026-72116", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: fix stale rx/tx ops after device removal RX: an RX_SETUP update(!) for an existing op skipped can_rx_register() unconditionally, even when a concurrent NETDEV_UNREGISTER had already torn down its registration (op->rx_reg_dev == NULL). This silently did not re-enable frame delivery for that updated filter. bcm_rx_setup() now re-registers in that case, while leaving rx_ops with ifindex = 0 (all CAN devices) which never carry a tracked rx_reg_dev registered as-is. TX: bcm_notify() only handled bo->rx_ops on NETDEV_UNREGISTER, leaving tx_ops with an active cyclic transmission re-arming its hrtimer indefinitely to execute bcm_tx_timeout_handler(). Cancelling the hrtimer prevents the runaway timer and any injection into a later reused ifindex, since nothing else calls bcm_can_tx() for the op until an explicit TX_SETUP update re-arms it. Unlike bcm_rx_unreg(), which clears the tracked rx_reg_dev for rx_ops, the ifindex is intentionally left unchanged for tx_ops. bcm_tx_setup() always rejects ifindex 0, so clearing it would strand the op: neither a later TX_SETUP (bcm_find_op()) nor TX_DELETE (bcm_delete_tx_op()) could ever find it again, since both require an exact ifindex match.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72113", "url": "https://ubuntu.com/security/CVE-2026-72113", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: add missing device refcount for CAN filter removal sashiko-bot remarked a problem with a concurrent device unregistration in isotp.c which also is present in the bcm.c code. A former fix for raw.c commit c275a176e4b6 (\"can: raw: add missing refcount for memory leak fix\") introduced a netdevice_tracker which solves the issue for bcm.c too. bcm_release(), bcm_delete_rx_op() and bcm_notifier() relied on dev_get_by_index(ifindex) to re-find the device for an rx_op before unregistering its filter. If a concurrent NETDEV_UNREGISTER has already unlisted the device from the ifindex table, that lookup fails and can_rx_unregister() is silently skipped, leaving a stale CAN filter pointing at the soon-to-be-freed bcm_op/socket. Hold a netdev_hold()/netdev_put() tracked reference on op->rx_reg_dev from the moment the rx filter is registered in bcm_rx_setup() until it is unregistered in bcm_rx_unreg(), and use that reference directly in bcm_release() and bcm_delete_rx_op() instead of re-looking the device up by ifindex.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72114", "url": "https://ubuntu.com/security/CVE-2026-72114", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: validate frame length in bcm_rx_setup() for RTR replies bcm_tx_setup() validates cf->len against the CAN/CAN FD DLC limits before installing frames for TX_SETUP, but bcm_rx_setup() never did the same for the RTR-reply frame configured via RX_SETUP with RX_RTR_FRAME.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72119", "url": "https://ubuntu.com/security/CVE-2026-72119", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: extend bcm_tx_lock usage for data and timer updates Stage new CAN frame content for an existing tx op into a kmalloc()'d buffer and validate it there, mirroring the approach already used in bcm_rx_setup(). Only copy the validated data into op->frames while holding op->bcm_tx_lock, so bcm_can_tx() and bcm_tx_timeout_handler() can no longer observe a partially updated or unvalidated frame. Add a missing error path for memcpy_from_msg() when copying CAN frame data from userspace. Also move the kt_ival1/kt_ival2/ival1/ival2 updates in bcm_tx_setup() under op->bcm_tx_lock, and read kt_ival1/kt_ival2/count under the same lock in bcm_tx_set_expiry() and bcm_tx_timeout_handler(), closing the torn 64-bit ktime_t read on 32-bit platforms.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72118", "url": "https://ubuntu.com/security/CVE-2026-72118", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: fix CAN frame rx/tx statistics KCSAN detected a data race within the bcm_rx_handler() when two CAN frames have been simultaneously received and processed in a single rx op by two different CPUs. Use atomic operations with (signed) long data types to access the statistics in the hot path to fix the KCSAN complaint. Additionally simplify the update and check of statistics overflow by using the atomic operations in separate bcm_update_[rx|tx]_stats() functions. The rx variant runs under bcm_rx_update_lock to prevent races when resetting the two rx counters; the tx variant runs under bcm_tx_lock and only needs to guard its own counter's overflow. As the rx path resets its values already at LONG_MAX / 100, there is no conflict between the two locking domains (bcm_rx_update_lock vs. bcm_tx_lock) even for ops that use both paths. The rx statistics update and the frames_filtered update in bcm_rx_changed() were previously performed in two separate bcm_rx_update_lock sections. For an rx op subscribed on all interfaces (ifindex == 0), bcm_rx_handler() can run concurrently on different CPUs, so a counter reset by one CPU between these two sections could leave frames_filtered larger than frames_abs on another CPU, producing a bogus (even negative) reduction percentage in procfs. Update the statistics in the same critical section as bcm_rx_changed() to close this gap, which also removes the now unneeded extra lock/unlock pair around the traffic_flags calculation.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72121", "url": "https://ubuntu.com/security/CVE-2026-72121", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: add locking when updating filter and timer values KCSAN detected a simultaneous access to timer values that can be overwritten in bcm_rx_setup() when updating timer and filter content while bcm_rx_handler(), bcm_rx_timeout_handler() or bcm_rx_thr_handler() run concurrently on incoming CAN traffic. Protect the timer (ival1/ival2/kt_ival1/kt_ival2/kt_lastmsg) and filter (nframes/flags/frames/last_frames) updates in bcm_rx_setup() with a new per-op bcm_rx_update_lock, taken with the matching scope in the RX handlers. memcpy_from_msg() is staged into a temporary buffer before the lock is taken, since it can sleep and must not run under a spinlock. hrtimer_cancel() is always called without bcm_rx_update_lock held, since bcm_rx_timeout_handler()/bcm_rx_thr_handler() take the same lock and a running callback would otherwise deadlock against the canceller. Also close a related race: bcm_rx_setup() cleared the RTR flag in the stored reply frame's can_id as a separate, unprotected step after the frame content was already installed, so a concurrent bcm_rx_handler() could transmit a stale reply with CAN_RTR_FLAG still set. Fold that normalization into the initial frame preparation instead (on the staged buffer for updates, directly on op->frames pre-registration for new ops), so the installed frame is always atomically self-consistent. bcm_rx_handler()'s RX_RTR_FRAME check now takes a lock-protected snapshot of op->flags before deciding whether to call bcm_can_tx(), but does not hold the lock across that call. Also take a lock-protected snapshot of the currframe in bcm_can_tx() to avoid partly overwrites by content updates in bcm_tx_setup(). Finally check if a TX_RESET_MULTI_IDX/SETTIMER might have reset op->currframe between the two locked sections in bcm_can_tx(). Omit calling hrtimer_forward() with zero interval in bcm_rx_thr_handler(). kt_ival2 may have been concurrently cleared by bcm_rx_setup() before it cancels this timer, so check kt_ival2 inside the bcm_rx_update_lock.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-68428", "url": "https://ubuntu.com/security/CVE-2026-68428", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86/mmu: Fix use-after-free on vendor module reload mmu_destroy_caches() destroys pte_list_desc_cache and mmu_page_header_cache, but leaves both pointers unchanged. The pointers live in kvm.ko, and therefore survive when a vendor module is unloaded while kvm.ko remains loaded. If creation of pte_list_desc_cache fails during a subsequent vendor module load, its assignment sets pte_list_desc_cache to NULL and the error path calls mmu_destroy_caches(). mmu_page_header_cache still points to the cache destroyed during the preceding vendor module unload. Passing that stale pointer to kmem_cache_destroy() causes a slab use-after-free. Reproduce the issue on a v7.1.3 kernel with CONFIG_KASAN=y, CONFIG_KASAN_GENERIC=y, CONFIG_KVM=m, and CONFIG_KVM_INTEL=m. A one-shot test hook forces pte_list_desc_cache to NULL on the second invocation of kvm_mmu_vendor_module_init(): 1. Load kvm.ko and kvm-intel.ko, creating both caches. 2. Unload only kvm_intel, leaving kvm.ko loaded. 3. Reload kvm_intel and force initialization through the -ENOMEM path. KASAN reports: BUG: KASAN: slab-use-after-free in kvm_mmu_vendor_module_init+0x5b/0x170 [kvm] ... kmem_cache_destroy+0x21/0x1d0 kvm_mmu_vendor_module_init+0x5b/0x170 [kvm] ... Allocated by task 16817: __kmem_cache_create_args+0x12c/0x3b0 __kmem_cache_create.constprop.0+0xb6/0xf0 [kvm] kvm_mmu_vendor_module_init+0x13b/0x170 [kvm] ... Freed by task 16820: kmem_cache_destroy+0x117/0x1d0 kvm_mmu_vendor_module_exit+0x21/0x30 [kvm] Clear both pointers immediately after destroying their caches so that the stored state reflects the caches' lifetime and repeated cleanup is safe. With the fix applied, the same injected vendor module reload fails with -ENOMEM as expected and produces no KASAN report.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64562", "url": "https://ubuntu.com/security/CVE-2026-64562", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: nVMX: Hide shadow VMCS right after VMCLEAR free_nested() frees the shadow VMCS while vmcs01 still points to it. But because it is asynchronous with respect to loaded_vmcs_clear(), the vCPU might migrate before the pointer is cleared and __loaded_vmcs_clear() may then execute VMCLEAR. The VMCS needs to stay attached until its explicit VMCLEAR completes, but then it can be hidden and the page safely freed.", "cve_priority": "high", "cve_public_date": "2026-08-04 07:16:00 UTC" }, { "cve": "CVE-2026-64561", "url": "https://ubuntu.com/security/CVE-2026-64561", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Check for invalid/obsolete root *after* making MMU pages available Check for a \"stale\" page fault, i.e. for an invalid and/or obsolete root, after making MMU pages available for the shadow MMU. If reclaiming shadow pages zaps an in-use root, i.e. marks it invalid, then KVM will attempt to map memory into an invalid root. On its own, populating an invalid root is \"fine\", but because child shadow pages inherit their parent's role, any children created during the map/fetch will be created as invalid pages, thus violating KVM's invariant that invalid pages are never on the list of active MMU pages. Note, the underlying flaw has existed since KVM first started tracking invalid roots in 2008 (commit 2e53d63acba7, \"KVM: MMU: ignore zapped root pagetables\"), but the true badness only came along in 2020 (Linux 5.9) with the invariant that invalid shadow pages can't be on the list of active pages. Note #2, inheriting role.invalid when creating child shadow pages is also far from ideal; that flaw will be addressed separately.", "cve_priority": "medium", "cve_public_date": "2026-08-04 07:16:00 UTC" }, { "cve": "CVE-2026-53090", "url": "https://ubuntu.com/security/CVE-2026-53090", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix ld_{abs,ind} failure path analysis in subprogs Usage of ld_{abs,ind} instructions got extended into subprogs some time ago via commit 09b28d76eac4 (\"bpf: Add abnormal return checks.\"). These are only allowed in subprograms when the latter are BTF annotated and have scalar return types. The code generator in bpf_gen_ld_abs() has an abnormal exit path (r0=0 + exit) from legacy cBPF times. While the enforcement is on scalar return types, the verifier must also simulate the path of abnormal exit if the packet data load via ld_{abs,ind} failed. This is currently not the case. Fix it by having the verifier simulate both success and failure paths, and extend it in similar ways as we do for tail calls. The success path (r0=unknown, continue to next insn) is pushed onto stack for later validation and the r0=0 and return to the caller is done on the fall-through side.", "cve_priority": "high", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-64564", "url": "https://ubuntu.com/security/CVE-2026-64564", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: don't free the ASCONF's own transport in DEL-IP processing sctp_process_asconf() caches the transport the ASCONF chunk is processed against in asconf->transport (== chunk->transport, set once in sctp_rcv()). For an ASCONF located through its Address Parameter by __sctp_rcv_asconf_lookup(), that cached transport corresponds to the Address Parameter, which need not be the packet's source address. sctp_process_asconf_param() rejects a DEL-IP for the packet source address (ADDIP D8, SCTP_ERROR_DEL_SRC_IP), but nothing protects asconf->transport. A single ASCONF can therefore carry, in order: [Address Parameter L] [DEL-IP L] [DEL-IP 0.0.0.0] where L differs from the source. The DEL-IP for L passes the D8 check and calls sctp_assoc_rm_peer() on the transport that asconf->transport still points at, freeing it (RCU-deferred). The following wildcard DEL-IP then reuses the now-dangling asconf->transport in sctp_assoc_set_primary() and sctp_assoc_del_nonprimary_peers(): set_primary() dereferences the freed transport (->ipaddr, ->state) and plants the dangling pointer into asoc->peer.primary_path / active_path, and del_nonprimary_peers(), keeping only the pointer that is no longer on the list, removes every real transport, leaving the association with a transport_count of 0 and primary_path/active_path pointing at freed memory. Reject a DEL-IP that targets the transport the ASCONF is being processed against, mirroring the existing source-address guard, so the wildcard branch can never reuse a freed transport.", "cve_priority": "critical", "cve_public_date": "2026-08-04 07:16:00 UTC" }, { "cve": "CVE-2026-68399", "url": "https://ubuntu.com/security/CVE-2026-68399", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix UAF in sock clone early bailouts Similar to recent commit 9b51a6155d14 (\"bpf,fork: wipe ->bpf_storage before bailouts that access it\"), sk_clone() performs an initial shallow copy of the socket field ->sk_bpf_storage via sock_copy() for the cloned socket newsk. If sk_clone() bails out early (e.g. if sk_filter_charge() fails) prior to calling bpf_sk_storage_clone(), newsk->sk_bpf_storage still points to the parent socket's BPF local storage. When newsk is subsequently freed via sk_free(), the deallocation path (__sk_destruct() -> bpf_sk_storage_free()) destroys the parent socket's BPF local storage, leading to a use-after-free (UAF) on the parent socket. Fix this by resetting newsk->sk_bpf_storage to NULL immediately after sock_copy() in sk_clone(), and remove the now redundant initialization from bpf_sk_storage_clone().", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2025-38563", "url": "https://ubuntu.com/security/CVE-2025-38563", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf/core: Prevent VMA split of buffer mappings The perf mmap code is careful about mmap()'ing the user page with the ringbuffer and additionally the auxiliary buffer, when the event supports it. Once the first mapping is established, subsequent mapping have to use the same offset and the same size in both cases. The reference counting for the ringbuffer and the auxiliary buffer depends on this being correct. Though perf does not prevent that a related mapping is split via mmap(2), munmap(2) or mremap(2). A split of a VMA results in perf_mmap_open() calls, which take reference counts, but then the subsequent perf_mmap_close() calls are not longer fulfilling the offset and size checks. This leads to reference count leaks. As perf already has the requirement for subsequent mappings to match the initial mapping, the obvious consequence is that VMA splits, caused by resizing of a mapping or partial unmapping, have to be prevented. Implement the vm_operations_struct::may_split() callback and return unconditionally -EINVAL. That ensures that the mapping offsets and sizes cannot be changed after the fact. Remapping to a different fixed address with the same size is still possible as it takes the references for the new mapping and drops those of the old mapping.", "cve_priority": "high", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2025-38565", "url": "https://ubuntu.com/security/CVE-2025-38565", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf/core: Exit early on perf_mmap() fail When perf_mmap() fails to allocate a buffer, it still invokes the event_mapped() callback of the related event. On X86 this might increase the perf_rdpmc_allowed reference counter. But nothing undoes this as perf_mmap_close() is never called in this case, which causes another reference count leak. Return early on failure to prevent that.", "cve_priority": "low", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2025-38187", "url": "https://ubuntu.com/security/CVE-2025-38187", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/nouveau: fix a use-after-free in r535_gsp_rpc_push() The RPC container is released after being passed to r535_gsp_rpc_send(). When sending the initial fragment of a large RPC and passing the caller's RPC container, the container will be freed prematurely. Subsequent attempts to send remaining fragments will therefore result in a use-after-free. Allocate a temporary RPC container for holding the initial fragment of a large RPC when sending. Free the caller's container when all fragments are successfully sent. [ Rebase onto Blackwell changes. - Danilo ]", "cve_priority": "high", "cve_public_date": "2025-07-04 14:15:00 UTC" }, { "cve": "CVE-2025-38069", "url": "https://ubuntu.com/security/CVE-2025-38069", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: endpoint: pci-epf-test: Fix double free that causes kernel to oops Fix a kernel oops found while testing the stm32_pcie Endpoint driver with handling of PERST# deassertion: During EP initialization, pci_epf_test_alloc_space() allocates all BARs, which are further freed if epc_set_bar() fails (for instance, due to no free inbound window). However, when pci_epc_set_bar() fails, the error path: pci_epc_set_bar() -> pci_epf_free_space() does not clear the previous assignment to epf_test->reg[bar]. Then, if the host reboots, the PERST# deassertion restarts the BAR allocation sequence with the same allocation failure (no free inbound window), creating a double free situation since epf_test->reg[bar] was deallocated and is still non-NULL. Thus, make sure that pci_epf_alloc_space() and pci_epf_free_space() invocations are symmetric, and as such, set epf_test->reg[bar] to NULL when memory is freed. [kwilczynski: commit log]", "cve_priority": "low", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-40014", "url": "https://ubuntu.com/security/CVE-2025-40014", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: objtool, spi: amd: Fix out-of-bounds stack access in amd_set_spi_freq() If speed_hz < AMD_SPI_MIN_HZ, amd_set_spi_freq() iterates over the entire amd_spi_freq array without breaking out early, causing 'i' to go beyond the array bounds. Fix that by stopping the loop when it gets to the last entry, so the low speed_hz value gets clamped up to AMD_SPI_MIN_HZ. Fixes the following warning with an UBSAN kernel: drivers/spi/spi-amd.o: error: objtool: amd_set_spi_freq() falls through to next function amd_spi_set_opcode()", "cve_priority": "low", "cve_public_date": "2025-04-18 07:15:00 UTC" }, { "cve": "CVE-2025-21985", "url": "https://ubuntu.com/security/CVE-2025-21985", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix out-of-bound accesses [WHAT & HOW] hpo_stream_to_link_encoder_mapping has size MAX_HPO_DP2_ENCODERS(=4), but location can have size up to 6. As a result, it is necessary to check location against MAX_HPO_DP2_ENCODERS. Similiarly, disp_cfg_stream_location can be used as an array index which should be 0..5, so the ASSERT's conditions should be less without equal.", "cve_priority": "medium", "cve_public_date": "2025-04-01 16:15:00 UTC" }, { "cve": "CVE-2024-56552", "url": "https://ubuntu.com/security/CVE-2024-56552", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc_submit: fix race around suspend_pending Currently in some testcases we can trigger: xe 0000:03:00.0: [drm] Assertion `exec_queue_destroyed(q)` failed! .... WARNING: CPU: 18 PID: 2640 at drivers/gpu/drm/xe/xe_guc_submit.c:1826 xe_guc_sched_done_handler+0xa54/0xef0 [xe] xe 0000:03:00.0: [drm] *ERROR* GT1: DEREGISTER_DONE: Unexpected engine state 0x00a1, guc_id=57 Looking at a snippet of corresponding ftrace for this GuC id we can see: 162.673311: xe_sched_msg_add: dev=0000:03:00.0, gt=1 guc_id=57, opcode=3 162.673317: xe_sched_msg_recv: dev=0000:03:00.0, gt=1 guc_id=57, opcode=3 162.673319: xe_exec_queue_scheduling_disable: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0x29, flags=0x0 162.674089: xe_exec_queue_kill: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0x29, flags=0x0 162.674108: xe_exec_queue_close: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0xa9, flags=0x0 162.674488: xe_exec_queue_scheduling_done: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0xa9, flags=0x0 162.678452: xe_exec_queue_deregister: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0xa1, flags=0x0 It looks like we try to suspend the queue (opcode=3), setting suspend_pending and triggering a disable_scheduling. The user then closes the queue. However the close will also forcefully signal the suspend fence after killing the queue, later when the G2H response for disable_scheduling comes back we have now cleared suspend_pending when signalling the suspend fence, so the disable_scheduling now incorrectly tries to also deregister the queue. This leads to warnings since the queue has yet to even be marked for destruction. We also seem to trigger errors later with trying to double unregister the same queue. To fix this tweak the ordering when handling the response to ensure we don't race with a disable_scheduling that didn't actually intend to perform an unregister. The destruction path should now also correctly wait for any pending_disable before marking as destroyed. (cherry picked from commit f161809b362f027b6d72bd998e47f8f0bad60a2e)", "cve_priority": "medium", "cve_public_date": "2024-12-27 15:15:00 UTC" }, { "cve": "CVE-2025-21687", "url": "https://ubuntu.com/security/CVE-2025-21687", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vfio/platform: check the bounds of read/write syscalls count and offset are passed from user space and not checked, only offset is capped to 40 bits, which can be used to read/write out of bounds of the device.", "cve_priority": "medium", "cve_public_date": "2025-02-10 16:15:00 UTC" }, { "cve": "CVE-2026-64560", "url": "https://ubuntu.com/security/CVE-2026-64560", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: posix-cpu-timers: Prevent UAF caused by non-leader exec() race Wongi and Jungwoo decoded and reported a non-leader exec() related race which can result in an UAF: sys_timer_delete()\t\t\texec() posix_cpu_timer_del() // Observes old leader p = pid_task(pid, pid_type);\t\tde_thread() \t\t\t\t\t switch_leader(); \t\t\t\t\t release_task(old_leader) \t\t\t\t\t __exit_signal(old_leader) \t\t\t\t\t sighand = lock(old_leader, sighand); \t\t\t\t\t posix_cpu_timers*_exit(); sighand = lock_task_sighand(p)\t unhash_task(old_leader); sh = lock(p, sighand)\t \t old_leader->sighand = NULL; \t\t\t\t\t unlock(sighand); (p->sighand == NULL) \tunlock(sh) \treturn NULL; // Returns without action if(!sighand) return 0; free_posix_timer(); This is \"harmless\" unless the deleted timer was armed and enqueued in p->signal because on exec() a TGID targeted timer is inherited. As sys_timer_delete() freed the underlying posix timer object run_posix_cpu_timers() or any timerqueue related add/delete operations on other timers will access the freed object's timerqueue node, which results in an UAF. There is a similar problem vs. posix_cpu_timer_set(). For regular posix timers it just transiently returns -ESRCH to user space, but for the use case in do_cpu_nanosleep() it's the same UAF just that the k_itimer is allocated on the stack. Also posix_cpu_timer_rearm() fails to rearm the timer, which means it stops to expire. While debating solutions Frederic pointed out another problem: posix_cpu_timer_del(tmr) \t\t\t\t\t__exit_signal(p) \t\t\t\t\t posix_cpu_timers*_exit(p); \t\t\t\t\t unhash_task(p); \t\t\t\t\t p->sighand = NULL; sh = lock_task_sighand(p) sighand = p->sighand; \tif (!sighand) \t return NULL; \tlock(sighand); if (!sh) \tWARN_ON_ONCE(timer_queued(tmr)); On weakly ordered architectures it is not guaranteed that posix_cpu_timer_del() will observe the stores in posix_cpu_timers*_exit() when p->sighand is observed as NULL, which means the WARN() can be a false positive. Solve these issues by: 1) Changing the store in __exit_signal() to smp_store_release(). 2) Adding a smp_acquire__after_ctrl_dep() into the !sighand path of lock_task_sighand(). 3) Creating a helper function for looking up the task and locking sighand which does not return when sighand == NULL. Instead it retries the task lookup and only if that fails it gives up. 4) Using that helper in the three affected functions. #1/#2 ensures that the reader side which observes sighand == NULL also observes all preceeding stores, i.e. the stores in posix_cpu_timers*_exit() and the ones in unhash_task(). #3 ensures that the above described non-leader exec() situation is handled gracefully. When the task lookup returns the old leader, but sighand == NULL then it retries. In the non-leader exec() case the subsequent task lookup will observe the new leader due to #1/#2. In normal exit() scenarios the subsequent lookup fails. When the task lookup fails, the function also checks whether the timer is still enqueued and issues a warning if that's the case. Unfortunately there is nothing which can be done about it, but as the task is already not longer visible the timer should not be accessed anymore. This check also requires memory ordering, which is not provided when the first lookup fails. To achieve that the check is preceeded by a smp_rmb() which pairs with the smp_wmb() in write_seqlock() in __exit_signal(). That ensures that the stores in posix_cpu_timers*_exit() are visible. The history of the non-leader exec() issue goes back to the early days of posix CPU timers, which stored a pointer to the group leader task in the timer. That obviously fails when a non-leader exec() switches the leader. commit e0a70217107e (\"posix-cpu-timers: workaround to suppress the problems with mt exec\") added a temporary workaround for that in 2010 which surv ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-07-29 17:16:00 UTC" }, { "cve": "CVE-2026-53365", "url": "https://ubuntu.com/security/CVE-2026-53365", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: fix zerocopy completion for multi-skb sends When a large message is fragmented into multiple skbs, the zerocopy uarg is only allocated and attached to the last skb in the loop. Non-final skbs carry pinned user pages with no completion tracking, so the kernel has no way to notify userspace when those pages are safe to reuse. If the loop breaks early the uarg is never allocated at all, leaking pinned pages with no completion notification. Fix this by following the approach used by TCP: allocate the zerocopy uarg (if not provided by the caller) before the send loop and attach it to every skb via skb_zcopy_set(), which takes a reference per skb. Each skb's completion properly decrements the refcount, and the notification only fires after the last skb is freed. On failure, if no data was sent, the uarg is cleanly aborted via net_zcopy_put_abort(). This issue was initially discovered by sashiko while reviewing commit 1cb36e252211 (\"vsock/virtio: fix MSG_ZEROCOPY pinned-pages accounting\") but was pre-existing.", "cve_priority": "high", "cve_public_date": "2026-07-13 18:16:00 UTC" }, { "cve": "CVE-2025-37964", "url": "https://ubuntu.com/security/CVE-2025-37964", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/mm: Eliminate window where TLB flushes may be inadvertently skipped tl;dr: There is a window in the mm switching code where the new CR3 is set and the CPU should be getting TLB flushes for the new mm. But should_flush_tlb() has a bug and suppresses the flush. Fix it by widening the window where should_flush_tlb() sends an IPI. Long Version: === History === There were a few things leading up to this. First, updating mm_cpumask() was observed to be too expensive, so it was made lazier. But being lazy caused too many unnecessary IPIs to CPUs due to the now-lazy mm_cpumask(). So code was added to cull mm_cpumask() periodically[2]. But that culling was a bit too aggressive and skipped sending TLB flushes to CPUs that need them. So here we are again. === Problem === The too-aggressive code in should_flush_tlb() strikes in this window: \t// Turn on IPIs for this CPU/mm combination, but only \t// if should_flush_tlb() agrees: \tcpumask_set_cpu(cpu, mm_cpumask(next)); \tnext_tlb_gen = atomic64_read(&next->context.tlb_gen); \tchoose_new_asid(next, next_tlb_gen, &new_asid, &need_flush); \tload_new_mm_cr3(need_flush); \t// ^ After 'need_flush' is set to false, IPIs *MUST* \t// be sent to this CPU and not be ignored. this_cpu_write(cpu_tlbstate.loaded_mm, next); \t// ^ Not until this point does should_flush_tlb() \t// become true! should_flush_tlb() will suppress TLB flushes between load_new_mm_cr3() and writing to 'loaded_mm', which is a window where they should not be suppressed. Whoops. === Solution === Thankfully, the fuzzy \"just about to write CR3\" window is already marked with loaded_mm==LOADED_MM_SWITCHING. Simply checking for that state in should_flush_tlb() is sufficient to ensure that the CPU is targeted with an IPI. This will cause more TLB flush IPIs. But the window is relatively small and I do not expect this to cause any kind of measurable performance impact. Update the comment where LOADED_MM_SWITCHING is written since it grew yet another user. Peter Z also raised a concern that should_flush_tlb() might not observe 'loaded_mm' and 'is_lazy' in the same order that switch_mm_irqs_off() writes them. Add a barrier to ensure that they are observed in the order they are written.", "cve_priority": "high", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2026-53389", "url": "https://ubuntu.com/security/CVE-2026-53389", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/tcp-ao: fix use-after-free of key in del_async path In tcp_ao_delete_key(), the del_async path skips the current_key and rnext_key validity checks present in the synchronous path, assuming these pointers are always NULL on LISTEN sockets. However, if a key was added with set_current=1/set_rnext=1 while the socket was in CLOSE state, current_key and rnext_key will be non-NULL after listen() transitions the socket to LISTEN. When such a key is deleted with del_async=1, hlist_del_rcu() and call_rcu() free the key without clearing the dangling pointers. After the RCU grace period, getsockopt(TCP_AO_INFO) dereferences current_key->sndid and rnext_key->rcvid from freed slab memory. Clear current_key and rnext_key in the del_async path when they reference the key being deleted.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53393", "url": "https://ubuntu.com/security/CVE-2026-53393", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: reset write verifier on deferred writeback errors nfsd_vfs_write() and nfsd_commit() both call filemap_check_wb_err() to detect deferred writeback errors, but neither rotates the server's write verifier (nn->writeverf) when this check fails. Every other durable-storage-failure path in these functions calls commit_reset_write_verifier() before returning an error. The missing rotation means clients holding UNSTABLE write data under the current verifier will COMMIT, receive the unchanged verifier back, and conclude their data is durable — silently dropping data that failed writeback. This violates the UNSTABLE+COMMIT durability contract (RFC 1813 §3.3.7, RFC 8881 §18.32). Add commit_reset_write_verifier() calls at both filemap_check_wb_err() error sites, matching the pattern used by adjacent error paths in the same functions. The helper already filters -EAGAIN and -ESTALE internally, so the calls are unconditionally safe.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53400", "url": "https://ubuntu.com/security/CVE-2026-53400", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: core: fix adapter registration race Adapters can be looked up based on their id using i2c_get_adapter() which takes a reference to the embedded struct device. Make sure that the adapter (including its struct device) has been initialised before adding it to the IDR to avoid accessing uninitialised data which could, for example, lead to NULL-pointer dereferences or use-after-free. Note that the i2c-dev chardev, which is registered from a bus notifier, currently uses i2c_get_adapter() so the adapter needs to be added to the IDR before registration.", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63806", "url": "https://ubuntu.com/security/CVE-2026-63806", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: Replace guest-triggerable BUG_ON() in ioeventfd datamatch with get_unaligned() Drop a BUG_ON() that has been reachable since it was first added, way back in 2009, and instead use get_unaligned() to perform potentially-unaligned accesses. For a given store, KVM x86's emulator tracks the entire value in the destination operand, x86_emulate_ctxt.dst. If the destination is memory, and the target splits multiple pages and/or is emulated MMIO, then KVM handles each fragment independently. E.g. on a page split starting at page offset 0xffc, KVM writes 4 bytes to the first page, then the remaining bytes to the second page, using ctxt->dst as the source for both (with appropriate offsets). If the destination splits a page *and* hits emulated MMIO on the second page, then KVM will complete the write to the first page, then emulate the MMIO access to the second page. If there is a datamatch-enabled ioeventfd at offset 0 of the second page, then KVM will process the remainder of the store as a potential ioeventfd signal. Putting it all together, if the guest emits a store that splits a page starting at page offset N, and the second page has a datamatch-enabled ioeventfd at offset 0, then KVM will check for datamatch using &dst.valptr[N] as the source. Due to dst (and thus dst.valptr) being 32-byte aligned, if N is not aligned to @len, the BUG_ON() fires. E.g. with a 16-byte store at page offset 0xffc, to an ioeventfd of len 8, all initial checks in ioeventfd_in_range() will succeed, and the BUG_ON() fires due to @val being 4-byte aligned, but not 8-byte aligned. ------------[ cut here ]------------ kernel BUG at arch/x86/kvm/../../../virt/kvm/eventfd.c:783! Oops: invalid opcode: 0000 [#1] SMP CPU: 0 UID: 1000 PID: 615 Comm: repro Not tainted 7.1.0-rc2-ff238429d1ea #365 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:ioeventfd_write+0x6c/0x70 [kvm] Call Trace: __kvm_io_bus_write+0x85/0xb0 [kvm] kvm_io_bus_write+0x53/0x80 [kvm] vcpu_mmio_write+0x66/0xf0 [kvm] emulator_read_write_onepage+0x12a/0x540 [kvm] emulator_read_write+0x109/0x2b0 [kvm] x86_emulate_insn+0x4f8/0xfb0 [kvm] x86_emulate_instruction+0x181/0x790 [kvm] kvm_mmu_page_fault+0x313/0x630 [kvm] vmx_handle_exit+0x18a/0x590 [kvm_intel] kvm_arch_vcpu_ioctl_run+0xc81/0x1c90 [kvm] kvm_vcpu_ioctl+0x2d5/0x970 [kvm] __x64_sys_ioctl+0x8a/0xd0 do_syscall_64+0xb7/0x890 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f19c931a9bf Modules linked in: kvm_intel kvm irqbypass ---[ end trace 0000000000000000 ]--- In a perfect world, the fix would be to simply delete the BUG_ON(), as KVM x86 doesn't perform alignment checks on \"normal\" memory accesses at CPL0. Sadly, C99 ruins all the fun; while the x86 architecture plays nice, dereferencing an unaligned pointer directly is undefined behavior in C, e.g. triggers splats when running with CONFIG_UBSAN_ALIGNMENT=y.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63940", "url": "https://ubuntu.com/security/CVE-2026-63940", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: SEV: Ignore Port I/O requests of length '0' Explicitly ignore Port I/O requests of length '0' (or count '0'), so that setting up the software scratch area (and other code) doesn't have to worry about underflowing the length, and to allow for WARNing on trying to configure the scratch area with len==0.", "cve_priority": "critical", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-53387", "url": "https://ubuntu.com/security/CVE-2026-53387", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: light: veml6075: add bounds check to veml6075_it_ms index veml6075_it_ms has 5 elements but VEML6075_CONF_IT can yield values 0-7. If it returns a value >= 5, this causes an out-of-bounds array access. Add a bounds check and return -EINVAL if the index is out of range. The problem values are reserved so should never be read from the register. Hence this is hardening against fault device, missprogramming or bus corruption.", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53070", "url": "https://ubuntu.com/security/CVE-2026-53070", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: disable BH before calling udp_tunnel_xmit_skb() udp_tunnel_xmit_skb() / udp_tunnel6_xmit_skb() are expected to run with BH disabled. After commit 6f1a9140ecda (\"add xmit recursion limit to tunnel xmit functions\"), on the path: udp(6)_tunnel_xmit_skb() -> ip(6)tunnel_xmit() dev_xmit_recursion_inc()/dec() must stay balanced on the same CPU. Without local_bh_disable(), the context may move between CPUs, which can break the inc/dec pairing. This may lead to incorrect recursion level detection and cause packets to be dropped in ip(6)_tunnel_xmit() or __dev_queue_xmit(). Fix it by disabling BH around both IPv4 and IPv6 SCTP UDP xmit paths. In my testing, after enabling the SCTP over UDP: # ip net exec ha sysctl -w net.sctp.udp_port=9899 # ip net exec ha sysctl -w net.sctp.encap_port=9899 # ip net exec hb sysctl -w net.sctp.udp_port=9899 # ip net exec hb sysctl -w net.sctp.encap_port=9899 # ip net exec ha iperf3 -s - without this patch: # ip net exec hb iperf3 -c 192.168.0.1 --sctp [ 5] 0.00-10.00 sec 37.2 MBytes 31.2 Mbits/sec sender [ 5] 0.00-10.00 sec 37.1 MBytes 31.1 Mbits/sec receiver - with this patch: # ip net exec hb iperf3 -c 192.168.0.1 --sctp [ 5] 0.00-10.00 sec 3.14 GBytes 2.69 Gbits/sec sender [ 5] 0.00-10.00 sec 3.14 GBytes 2.69 Gbits/sec receiver", "cve_priority": "low", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-43216", "url": "https://ubuntu.com/security/CVE-2026-43216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: Drop the lock in skb_may_tx_timestamp() skb_may_tx_timestamp() may acquire sock::sk_callback_lock. The lock must not be taken in IRQ context, only softirq is okay. A few drivers receive the timestamp via a dedicated interrupt and complete the TX timestamp from that handler. This will lead to a deadlock if the lock is already write-locked on the same CPU. Taking the lock can be avoided. The socket (pointed by the skb) will remain valid until the skb is released. The ->sk_socket and ->file member will be set to NULL once the user closes the socket which may happen before the timestamp arrives. If we happen to observe the pointer while the socket is closing but before the pointer is set to NULL then we may use it because both pointer (and the file's cred member) are RCU freed. Drop the lock. Use READ_ONCE() to obtain the individual pointer. Add a matching WRITE_ONCE() where the pointer are cleared.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-64244", "url": "https://ubuntu.com/security/CVE-2026-64244", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drivers/base/memory: set mem->altmap after successful device registration If __add_memory_block() fails at xa_store() (under memory pressure for example), device_unregister() is called, which eventually triggers memory_block_release() with mem->altmap still set, causing a WARN_ON(mem->altmap). This was triggered by modifying virtio-mem driver. Fix this by delaying the assignment of mem->altmap until after __add_memory_block() has succeeded.", "cve_priority": "medium", "cve_public_date": "2026-07-24 16:16:00 UTC" }, { "cve": "CVE-2026-53384", "url": "https://ubuntu.com/security/CVE-2026-53384", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: 8250_dw: unregister 8250 port if clk_notifier_register() fails dw8250_probe() registers the 8250 port via serial8250_register_8250_port() and then, if the device has a clock, registers a clock notifier. If clk_notifier_register() fails, probe returns the error but leaves the 8250 port registered. The matching serial8250_unregister_port() lives in dw8250_remove(), which is not called when probe fails, so the port slot stays occupied until the device is rebound or the system is rebooted. The devm-allocated driver data is freed while the port still references it (via the saved private_data and serial_in/serial_out callbacks), so any access to that port slot before a rebind is a use-after-free hazard. Unregister the port on the clk_notifier_register() error path.", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53390", "url": "https://ubuntu.com/security/CVE-2026-53390", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix out-of-bounds read in smb_check_perm_dacl() The permission-check ACE walk in smb_check_perm_dacl() validates the ACE header size and caps sid.num_subauth at SID_MAX_SUB_AUTHORITIES, but it never checks that ace->size is actually large enough to contain num_subauth sub-authorities before compare_sids() dereferences them. CIFS_SID_BASE_SIZE covers the SID header up to but excluding the sub_auth[] array, and offsetof(struct smb_ace, sid) is the ACE header, so the existing guards only guarantee the 8-byte SID base, i.e. zero sub-authorities. compare_sids() then reads ace->sid.sub_auth[i] for i < min(local_sid->num_subauth, ace->sid.num_subauth). The local comparison SIDs (sid_everyone, sid_unix_NFS_mode, and the id_to_sid() result) always have at least one sub-authority, and an attacker controls the ACE revision and authority bytes (which lie within the in-bounds SID base), so they can match one of those SIDs and force the sub_auth read. A crafted ACE with size == 16 and num_subauth >= 1 placed at the tail of the security descriptor therefore causes a heap out-of-bounds read of up to SID_MAX_SUB_AUTHORITIES * sizeof(__le32) bytes past the pntsd allocation. The security descriptor is loaded by ksmbd_vfs_get_sd_xattr() into a buffer sized exactly to the on-disk data (kzalloc(sd_size) in ndr_decode_v4_ntacl()), so the read lands past the allocation. The malformed descriptor can be stored verbatim via SMB2_SET_INFO (the DACL is not normalised before being written to the security.NTACL xattr) and the read fires on a subsequent SMB2_CREATE access check, making this reachable by an authenticated client on a share that uses ACL xattrs. Add the missing num_subauth-versus-ace_size check, mirroring the identical guards already present in the sibling parsers parse_dacl() and smb_inherit_dacl().", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53391", "url": "https://ubuntu.com/security/CVE-2026-53391", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4/pNFS: reject zero-length r_addr in nfs4_decode_mp_ds_addr nfs4_decode_mp_ds_addr() decodes the r_netid and r_addr opaques of a netaddr4 from a GETDEVICEINFO multipath-DS body, then immediately calls strrchr(buf, '.') to locate the port separator. Both decodes use xdr_stream_decode_string_dup(), and the current code checks only \"nlen < 0\" / \"rlen < 0\" before dereferencing the returned string. When the on-wire opaque has length zero, xdr_stream_decode_opaque_inline() returns 0 and xdr_stream_decode_string_dup() falls through to its \"*str = NULL; return ret\" tail, leaving buf NULL with a return value of 0. The \"< 0\" check does not catch this, and the next line is strrchr(NULL, '.'), a kernel NULL pointer dereference reachable from any pNFS-flexfile client mounted against a malicious or compromised metadata server. Reject the zero-length cases explicitly so the decoder fails with -EBADMSG (treated as a malformed GETDEVICEINFO body) instead of panicking the client.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53397", "url": "https://ubuntu.com/security/CVE-2026-53397", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: fix posix_acl leak on SETACL decode failure nfsaclsvc_decode_setaclargs() and nfs3svc_decode_setaclargs() each call nfs_stream_decode_acl() twice, first for NFS_ACL and then for NFS_DFACL. Each successful call transfers ownership of a freshly allocated posix_acl into argp->acl_access or argp->acl_default. If the first call succeeds but the second fails, the decoder returns false and argp->acl_access is left dangling. ACLPROC2_SETACL.pc_release was wired to nfssvc_release_attrstat and ACLPROC3_SETACL.pc_release was wired to nfs3svc_release_fhandle. Both only call fh_put() and have no knowledge of the ACL fields on argp. The posix_acl_release() pairs sat at the out: labels inside nfsacld_proc_setacl() and nfsd3_proc_setacl(), but svc_process() skips pc_func when pc_decode returns false, so that cleanup is unreachable on decode failure: svc_process_common() pc_decode() /* decode_setaclargs: false */ /* pc_func skipped */ pc_release() /* fh_put only -- ACLs leaked */ The orphaned posix_acl is leaked for the lifetime of the server. Fix by adding nfsaclsvc_release_setacl() and nfs3svc_release_setacl(), which release both argp->acl_access and argp->acl_default in addition to fh_put(), and wiring them as pc_release for their respective SETACL procedures. pc_release runs on every path svc_process() takes after decode, including decode failure, so the posix_acl_release() pairs are removed from the proc functions' out: labels to keep ownership in one place. This matches the existing release_getacl() pattern used by the sibling GETACL procedures.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53398", "url": "https://ubuntu.com/security/CVE-2026-53398", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSD: Fix SECINFO_NO_NAME decode error cleanup nfsd4_decode_secinfo_no_name() currently initializes sin_exp after decoding sin_style. If the XDR stream is truncated, the decoder returns nfserr_bad_xdr before sin_exp is initialized. Since commit 3fdc54646234 (\"NFSD: Reduce amount of struct nfsd4_compoundargs that needs clearing\"), the inline iops array is not cleared between RPC calls. A failed SECINFO_NO_NAME decode can therefore leave sin_exp holding stale union contents from a previous operation. The error response path still invokes nfsd4_secinfo_no_name_release(), which calls exp_put() on a non-NULL sin_exp. Initialize sin_exp before the first failable decode step, matching nfsd4_decode_secinfo().", "cve_priority": "critical", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-64245", "url": "https://ubuntu.com/security/CVE-2026-64245", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: modedb: fix a possible UAF in fb_find_mode() If mode_option is NULL, it is assigned from mode_option_buf: if (!mode_option) { fb_get_options(NULL, &mode_option_buf); mode_option = mode_option_buf; } Later, name is assigned from mode_option: const char *name = mode_option; However, mode_option_buf is freed before name is no longer used: kfree(mode_option_buf); while name is still accessed by: if ((name_matches(db[i], name, namelen) || Since name aliases mode_option_buf, this may result in a use-after-free. Fix this by extending the lifetime of mode_option_buf until the end of the function by using scope-based resource management for cleanup.", "cve_priority": "low", "cve_public_date": "2026-07-24 16:16:00 UTC" }, { "cve": "CVE-2026-53403", "url": "https://ubuntu.com/security/CVE-2026-53403", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: Fix fb_new_modelist to prevent null-ptr-deref in fb_videomode_to_var info->var, a framebuffer's current mode, is expected to have a matching entry in info->modelist. var_to_display() relies on this and treats a failed fb_match_mode() as \"This should not happen\". fb_set_var() keeps it true by adding the mode to the list on every change, and do_register_framebuffer() does the same at registration. store_modes() replaces the modelist from userspace. fb_new_modelist() validates the new modes but does not check that info->var still has a match. It relies on fbcon_new_modelist() to re-point consoles, but that only handles consoles mapped to the framebuffer. With fbcon unbound there are none, so info->var is left describing a mode that is no longer in the list. A later console takeover runs var_to_display(), where fb_match_mode() returns NULL and leaves fb_display[i].mode NULL. fbcon_switch() passes it to display_to_var(), and fb_videomode_to_var() dereferences the NULL mode. Keep the current mode in the list in fb_new_modelist(), the same way fb_set_var() does.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-64246", "url": "https://ubuntu.com/security/CVE-2026-64246", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: reset: linkstation-poweroff: fix use-after-free in the linkstation_poweroff_init() Move of_node_put(dn) after the of_match_node() call, which still needs the node pointer. The node reference is correctly released after use.", "cve_priority": "medium", "cve_public_date": "2026-07-24 16:16:00 UTC" }, { "cve": "CVE-2026-63794", "url": "https://ubuntu.com/security/CVE-2026-63794", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: SVM: Fix page overflow in sev_dbg_crypt() for ENCRYPT path In sev_dbg_crypt(), the per-iteration transfer length is bounded by the source page offset (PAGE_SIZE - s_off) but not by the destination page offset (PAGE_SIZE - d_off). When d_off > s_off, the encrypt path (__sev_dbg_encrypt_user) performs a read-modify-write using a single-page intermediate buffer (dst_tpage): 1. __sev_dbg_decrypt() expands the size to round_up(len + (d_off & 15), 16) before issuing the PSP command. If len + (d_off & 15) > PAGE_SIZE, the PSP writes beyond the end of the 4096-byte dst_tpage allocation. 2. The subsequent memcpy()/copy_from_user() into page_address(dst_tpage) + (d_off & 15) of 'len' bytes overflows by up to 15 bytes under the same condition. Trigger example: s_off = 0, d_off = 1, debug.len = PAGE_SIZE - the PSP is instructed to write round_up(4097, 16) = 4112 bytes to a 4096-byte buffer. Fix by also bounding len by (PAGE_SIZE - d_off), the same check that sev_send_update_data() already performs for its single-page guest region. ================================================================== BUG: KASAN: slab-use-after-free in sev_dbg_crypt+0x993/0xd10 [kvm_amd] Write of size 4095 at addr ff110062293bb009 by task sev_dbg_test/228214 CPU: 96 UID: 0 PID: 228214 Comm: sev_dbg_test Tainted: G U W 7.0.0-smp--5ce9b0c48211-dbg #156 PREEMPTLAZY Tainted: [U]=USER, [W]=WARN Hardware name: Google Astoria/astoria, BIOS 0.20250817.1-0 08/25/2025 Call Trace: dump_stack_lvl+0x54/0x70 print_report+0xbc/0x260 kasan_report+0xa2/0xd0 kasan_check_range+0x25f/0x2c0 __asan_memcpy+0x40/0x70 sev_dbg_crypt+0x993/0xd10 [kvm_amd] sev_mem_enc_ioctl+0x33c/0x450 [kvm_amd] kvm_vm_ioctl+0x65d/0x6d0 [kvm] __se_sys_ioctl+0xb2/0x100 do_syscall_64+0xe8/0x870 entry_SYSCALL_64_after_hwframe+0x4b/0x53 The buggy address belongs to the physical page: page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x7fe72b6a0 pfn:0x62293bb memcg:ff11000112827d82 flags: 0x1400000000000000(node=1|zone=1) raw: 1400000000000000 0000000000000000 dead000000000122 0000000000000000 raw: 00000007fe72b6a0 0000000000000000 00000001ffffffff ff11000112827d82 page dumped because: kasan: bad access detected Memory state around the buggy address: ff110062293bbf00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff110062293bbf80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ff110062293bc000: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc ^ ff110062293bc080: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc ff110062293bc100: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc ================================================================== Disabling lock debugging due to kernel taint [sean: add sample KASAN splat, Fixes, and stable@]", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-64247", "url": "https://ubuntu.com/security/CVE-2026-64247", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86: hyper-v: Bound the bank index when querying sparse banks When checking if a VP ID is included in a sparse bank set, explicitly check that the ID can actually be contained in a sparse bank (the TLFS allows for a maximum of 64 banks of 64 vCPUs each). When handling a paravirtual TLB flush for L2, the VP ID is copied verbatim from the enlightened VMCS, without any bounds check, i.e. isn't guaranteed to be under the limit of 4096. Failure to check the bounds of the VP ID leads to an out-of-bounds read when testing the sparse bank, and super strictly speaking could lead to KVM performing an unnecessary TLB flush for an L2 vCPU. ================================================================== BUG: KASAN: use-after-free in hv_is_vp_in_sparse_set+0x85/0x100 [kvm] Read of size 8 at addr ffff88811ba5f598 by task hyperv_evmcs/2802 CPU: 12 UID: 1000 PID: 2802 Comm: hyperv_evmcs Not tainted 7.1.0-rc2 #7 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Call Trace: dump_stack_lvl+0x51/0x60 print_report+0xcb/0x5d0 kasan_report+0xb4/0xe0 kasan_check_range+0x35/0x1b0 hv_is_vp_in_sparse_set+0x85/0x100 [kvm] kvm_hv_flush_tlb+0xe9e/0x16c0 [kvm] kvm_hv_hypercall+0xe6b/0x1e60 [kvm] vmx_handle_exit+0x485/0x1b60 [kvm_intel] kvm_arch_vcpu_ioctl_run+0x22e3/0x5070 [kvm] kvm_vcpu_ioctl+0x5d0/0x10c0 [kvm] __x64_sys_ioctl+0x129/0x1a0 do_syscall_64+0xb9/0xcf0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f0e62d1a9bf The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffffffffffffffff pfn:0x11ba5f flags: 0x4000000000000000(zone=1) raw: 4000000000000000 0000000000000000 00000000ffffffff 0000000000000000 raw: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff88811ba5f480: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff88811ba5f500: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff >ffff88811ba5f580: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ^ ffff88811ba5f600: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff88811ba5f680: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ================================================================== Disabling lock debugging due to kernel taint Opportunistically add a compile time assertion to ensure the maximum number of sparse banks exactly matches the number of possible bits in the passed in mask. [sean: add KASAN splat, drop comment, add assert, massage changelog]", "cve_priority": "medium", "cve_public_date": "2026-07-24 16:16:00 UTC" }, { "cve": "CVE-2026-63795", "url": "https://ubuntu.com/security/CVE-2026-63795", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: 9p: avoid putting oldfid in p9_client_walk() error path When p9_client_walk() is called with clone set to false, fid aliases oldfid. If the walk subsequently fails after the request has been sent, the error path jumps to clunk_fid, which currently calls p9_fid_put(fid) unconditionally. This drops a reference to oldfid even though ownership of oldfid remains with the caller. If this is the last reference, oldfid can be clunked and destroyed while the caller still expects it to be valid. A later use or put of oldfid can then trigger a use-after-free or refcount underflow. Fix this by only putting fid in the clunk_fid error path when it does not alias oldfid, matching the existing guard in the error path below. This can be triggered when a multi-component walk is split into multiple p9_client_walk() calls and a later non-cloning walk fails. A reproducer and refcount warning logs are available on request.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63796", "url": "https://ubuntu.com/security/CVE-2026-63796", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: reject oversized group bitmap descriptors ocfs2_validate_gd_parent() only bounds bg_bits against the parent allocator's chain geometry. A malicious descriptor can still claim a bg_size/bg_bits pair that exceeds the bitmap bytes that physically fit in the group descriptor block, so later bitmap scans and bit updates can run past bg_bitmap. Add a physical-cap check based on ocfs2_group_bitmap_size() for the parent allocator type and reject descriptors whose bg_size or bg_bits exceed that capacity. Keep the existing chain geometry check so both the on-disk bitmap layout and the allocator metadata must agree before the descriptor is used. Validation reproduced this kernel report: KASAN use-after-free in _find_next_bit+0x7f/0xc0 Read of size 8 Call trace: dump_stack_lvl+0x66/0xa0 (?:?) print_report+0xd0/0x630 (?:?) _find_next_bit+0x7f/0xc0 (?:?) srso_alias_return_thunk+0x5/0xfbef5 (?:?) __virt_addr_valid+0x188/0x2f0 (?:?) kasan_report+0xe4/0x120 (?:?) ocfs2_find_max_contig_free_bits+0x35/0x70 (fs/ocfs2/suballoc.c:1375) ocfs2_block_group_set_bits+0x472/0x4b0 (fs/ocfs2/suballoc.c:1457) ocfs2_cluster_group_search+0x16b/0x440 (fs/ocfs2/suballoc.c:86) ocfs2_bg_discontig_fix_result+0x1ef/0x230 (fs/ocfs2/suballoc.c:1786) ocfs2_search_chain+0x8f8/0x10a0 (fs/ocfs2/suballoc.c:1886) get_page_from_freelist+0x70e/0x2370 (?:?) lock_release+0xc6/0x290 (?:?) do_raw_spin_unlock+0x9a/0x100 (?:?) kasan_unpoison+0x27/0x60 (?:?) __bfs+0x147/0x240 (?:?) get_page_from_freelist+0x83d/0x2370 (?:?) ocfs2_claim_suballoc_bits+0x38c/0xe70 (fs/ocfs2/suballoc.c:96) sched_domains_numa_masks_clear+0x70/0xd0 (?:?) check_irq_usage+0xe8/0xb70 (?:?) __ocfs2_claim_clusters+0x18d/0x4c0 (fs/ocfs2/suballoc.c:2497) check_path+0x24/0x50 (?:?) rcu_is_watching+0x20/0x50 (?:?) check_prev_add+0xfd/0xd00 (?:?) ocfs2_add_clusters_in_btree+0x17d/0x810 (fs/ocfs2/suballoc.c:?) __folio_batch_add_and_move+0x1f5/0x3d0 (?:?) ocfs2_add_inode_data+0xd9/0x120 (fs/ocfs2/suballoc.c:?) filemap_add_folio+0x105/0x1f0 (?:?) ocfs2_write_begin_nolock+0x29f7/0x2f80 (fs/ocfs2/suballoc.c:3043) ocfs2_read_inode_block+0xb5/0x110 (fs/ocfs2/suballoc.c:?) down_write+0xf5/0x180 (?:?) ocfs2_write_begin+0x180/0x240 (fs/ocfs2/suballoc.c:?) __mark_inode_dirty+0x758/0x9a0 (?:?) inode_to_bdi+0x41/0x90 (?:?) balance_dirty_pages_ratelimited_flags+0xf8/0x1d0 (?:?) generic_perform_write+0x252/0x440 (?:?) mnt_put_write_access_file+0x16/0x70 (?:?) file_update_time_flags+0xe4/0x200 (?:?) ocfs2_file_write_iter+0x80a/0x1320 (fs/ocfs2/suballoc.c:?) lock_acquire+0x184/0x2f0 (?:?) ksys_write+0xd2/0x170 (?:?) apparmor_file_permission+0xf5/0x310 (?:?) read_zero+0x8d/0x140 (?:?) lock_is_held_type+0x8f/0x100 (?:?)", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63797", "url": "https://ubuntu.com/security/CVE-2026-63797", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rpmsg: char: Fix use-after-free on probe error path rpmsg_chrdev_probe() stores the newly allocated eptdev in the default endpoint's priv pointer before calling rpmsg_chrdev_eptdev_add(). If rpmsg_chrdev_eptdev_add() then fails, its error path frees eptdev while the default endpoint may still dispatch callbacks with the stale priv pointer. Avoid publishing eptdev through the default endpoint until rpmsg_chrdev_eptdev_add() succeeds. Messages received before the priv pointer is published should be ignored by rpmsg_ept_cb(). Flow-control updates can hit rpmsg_ept_flow_cb() in the same window, so make both callbacks return success when priv is NULL.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-64249", "url": "https://ubuntu.com/security/CVE-2026-64249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fpga: region: fix use-after-free in child_regions_with_firmware() Move of_node_put(child_region) after the error print to avoid accessing freed memory when pr_err() references child_region. [ Yilun: Fix the Fixes tag ]", "cve_priority": "low", "cve_public_date": "2026-07-24 16:16:00 UTC" }, { "cve": "CVE-2026-63798", "url": "https://ubuntu.com/security/CVE-2026-63798", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: irqchip/imgpdc: Fix resource leak, add missing chained handler cleanup on remove The driver allocates domain generic chips using irq_alloc_domain_generic_chips() during probe and sets up chained handlers using irq_set_chained_handler_and_data(). However, on driver removal, the generic chips are not freed and the chained handlers are not removed. The generic chips remain on the global gc_list and may later be accessed by generic interrupt chip suspend, resume, or shutdown callbacks after the driver has been removed, potentially resulting in a use-after-free and kernel crash. The chained handlers that were installed in probe for peripheral and syswake interrupts are also left dangling, which can lead to spurious interrupts accessing freed memory. Fix these issues by: - Setting IRQ_DOMAIN_FLAG_DESTROY_GC flag in domain->flags, so the core code automatically removes generic chips when irq_domain_remove() is called - Clearing all chained handlers with NULL in pdc_intc_remove()", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63800", "url": "https://ubuntu.com/security/CVE-2026-63800", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pNFS: Fix use-after-free in pnfs_update_layout() When hitting the NFS_LAYOUT_RETURN branch in pnfs_update_layout(), the code calls pnfs_prepare_to_retry_layoutget(lo). If it succeeds, pnfs_put_layout_hdr(lo) is called before trace_pnfs_update_layout(), which still references 'lo'. This results in a use-after-free when the tracepoint accesses lo's fields. Fix this by moving the tracepoint call before pnfs_put_layout_hdr(lo).", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63801", "url": "https://ubuntu.com/security/CVE-2026-63801", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix slab-use-after-free Read in tipc_aead_decrypt_done tipc_aead_decrypt() goes straight from tipc_bearer_hold(b) to crypto_aead_decrypt(req) without taking a reference on the netns, unlike the encrypt path. When crypto_aead_decrypt() is offloaded asynchronously (e.g. the SIMD aead wrapper queuing to cryptd), the cryptd worker runs tipc_aead_decrypt_done() later. If the bearer's netns is torn down in the meantime, cleanup_net() -> tipc_exit_net() -> tipc_crypto_stop() frees the per-netns tipc_crypto, and the completion then reads it: tipc_aead_decrypt_done() dereferences aead->crypto->stats and aead->crypto->net, and tipc_crypto_rcv_complete() dereferences aead->crypto->aead[] and the node table -- reading freed memory. Decoded KASAN splat (v7.1-rc7, CONFIG_KASAN_INLINE + TIPC + TIPC_CRYPTO): BUG: KASAN: slab-use-after-free in tipc_aead_decrypt_done (net/tipc/crypto.c:999) Read of size 8 at addr ffff8881056258a8 by task kworker/u16:2/51 Workqueue: events_unbound Call Trace: tipc_aead_decrypt_done (net/tipc/crypto.c:999) process_one_work (kernel/workqueue.c:3314) worker_thread (kernel/workqueue.c:3397 kernel/workqueue.c:3478) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) Allocated by task 169: __kasan_kmalloc (mm/kasan/common.c:398 mm/kasan/common.c:415) tipc_crypto_start (net/tipc/crypto.c:1502) tipc_init_net (net/tipc/core.c:72) ops_init (net/core/net_namespace.c:137) setup_net (net/core/net_namespace.c:446) copy_net_ns (net/core/net_namespace.c:579) create_new_namespaces (kernel/nsproxy.c:132) __x64_sys_unshare (kernel/fork.c:3316) do_syscall_64 (arch/x86/entry/syscall_64.c:63) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Freed by task 8: kfree (mm/slub.c:6566) tipc_exit_net (net/tipc/core.c:119) cleanup_net (net/core/net_namespace.c:704) process_one_work (kernel/workqueue.c:3314) kthread (kernel/kthread.c:436) This is the same class of bug that commit e279024617134 (\"net/tipc: fix slab-use-after-free Read in tipc_aead_encrypt_done\") fixed for the encrypt side. The encrypt path takes maybe_get_net(aead->crypto->net) before crypto_aead_encrypt() and drops it with put_net() on the synchronous return paths and in tipc_aead_encrypt_done(); the -EINPROGRESS/-EBUSY return keeps the reference for the async callback to release. The decrypt path was left without the equivalent guard. Mirror the encrypt-side fix on the decrypt path: take a net reference before crypto_aead_decrypt() (failing with -ENODEV and the matching bearer put if it cannot be acquired), keep it across the -EINPROGRESS/-EBUSY async return, and drop it with put_net() on the synchronous success/error return and at the end of tipc_aead_decrypt_done(). Reproduced under KASAN on v7.1-rc7: a UDP bearer with a cluster key is flooded with crafted encrypted frames from an unknown peer (driving the cluster-key decrypt path) while the bearer's netns is repeatedly torn down. The completion must run asynchronously to outlive tipc_crypto_stop(); on x86 the stock aesni gcm(aes) now decrypts synchronously, so the async path was exercised via cryptd offload. The unguarded aead->crypto dereference in tipc_aead_decrypt_done() is the unpatched upstream path; tipc_aead_decrypt() still lacks maybe_get_net(aead->crypto->net), so the completion can outlive the free on any config where crypto_aead_decrypt() goes async. Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "high", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63802", "url": "https://ubuntu.com/security/CVE-2026-63802", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: blk-cgroup: fix UAF in __blkcg_rstat_flush() When multiple blkgs in the same blkcg are released concurrently, a use-after-free can occur. The race happens when one blkg's __blkcg_rstat_flush() removes another blkg's iostat entries via llist_del_all(). The second blkg sees an empty list and proceeds to free itself while the first is still iterating over its entries. Move the flush from __blkg_release() (RCU callback) to blkg_release() (before call_rcu). This ensures the RCU grace period waits for any concurrent flush's rcu_read_lock() section to complete before freeing.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63803", "url": "https://ubuntu.com/security/CVE-2026-63803", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hdlc_ppp: sync per-proto timers before freeing hdlc state Each PPP control protocol (LCP/IPCP/IPV6CP) embedded in struct ppp registers a timer via timer_setup(). That struct ppp is the hdlc->state allocation, which detach_hdlc_protocol() frees with kfree() in both teardown paths: unregister_hdlc_device() and the re-attach inside attach_hdlc_protocol(). The ppp proto never registered a .detach callback, so detach_hdlc_protocol() performs no timer synchronization before the kfree(). The only cancel, timer_delete(&proto->timer) in ppp_cp_event(), is partial (it does not wait for a running callback) and only runs on the ->CLOSED transition; ppp_stop()/ppp_close() do not sync either. A ppp_timer callback already executing (blocked on ppp->lock) survives the kfree and then dereferences proto->state / ppp->lock in freed memory, leading to a use-after-free. Fix this by adding a .detach helper that calls timer_shutdown_sync() on every per-proto timer. detach_hdlc_protocol() invokes proto->detach(dev) before kfree(hdlc->state), so timer_shutdown_sync() now runs on both free paths. timer_shutdown_sync() is used instead of timer_delete_sync() because the keepalive path re-arms the timer through add_timer()/mod_timer() and shutdown blocks any re-activation during teardown. Initialize the per-protocol timers in ppp_ioctl() when the protocol is attached, and remove the now-redundant timer_setup() from ppp_start(), so that the timers are initialized exactly once at attach time and ppp_timer_release() never operates on uninitialized timer_list structures. attach_hdlc_protocol() uses kmalloc() (not kzalloc), so struct ppp's protos[i].timer is uninitialized garbage until the first timer_setup(); without this init-at-attach, attaching the PPP protocol without ever bringing the device up would leave timer_shutdown_sync() operating on uninitialized memory in .detach. Moving the init out of ppp_start() (which only runs on NETDEV_UP) into the attach path makes the initialization unconditional and avoids initializing the same timer_list twice. This bug was found by static analysis.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63804", "url": "https://ubuntu.com/security/CVE-2026-63804", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gfs2: fix use-after-free in gfs2_qd_dealloc gfs2_qd_dealloc(), called as an RCU callback from gfs2_qd_dispose(), accesses the superblock object sdp through qd->qd_sbd after freeing qd. It does so to decrement sd_quota_count and wake up sd_kill_wait. However, by the time the RCU callback runs, gfs2_put_super() may have already freed sdp via free_sbd(). This can happen when gfs2_quota_cleanup() is called during unmount: it disposes of quota objects via call_rcu() and then waits on sd_kill_wait with a 60-second timeout. If the timeout expires, or if gfs2_gl_hash_clear() triggers additional qd_put() calls that schedule more RCU callbacks after the wait completes, gfs2_put_super() will proceed to free the superblock while RCU callbacks referencing it are still pending. Add an rcu_barrier() before free_sbd() in gfs2_put_super() to ensure all pending RCU callbacks (including gfs2_qd_dealloc) have completed before the superblock is freed.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63808", "url": "https://ubuntu.com/security/CVE-2026-63808", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exfat: fix potential use-after-free in exfat_find_dir_entry() In exfat_find_dir_entry(), the buffer_head obtained from exfat_get_dentry() is released with brelse(bh) before the fall-through TYPE_EXTEND branch reads the directory entry through ep (which points into bh->b_data): \tbrelse(bh); \tif (entry_type == TYPE_EXTEND) { \t\t... \t\tlen = exfat_extract_uni_name(ep, entry_uniname); \t\t... \t} After brelse() drops our reference, nothing guarantees that the underlying page backing bh->b_data remains valid for the subsequent exfat_extract_uni_name() read. This is the same pattern fixed in commit fc961522ddbd (\"exfat: Fix potential use after free in exfat_load_upcase_table()\"). Move brelse(bh) so it runs after ep is no longer dereferenced on each branch. Confirmed on QEMU x86_64 with CONFIG_KASAN=y + CONFIG_DEBUG_PAGEALLOC=y + CONFIG_PAGE_POISONING=y on linux-next, using a crafted exFAT image (long filename with same-hash collisions forcing the TYPE_EXTEND path). With a debug-only invalidate_bdev() inserted between brelse(bh) and the ep read to make the stale-deref window deterministic, the unpatched kernel faults: BUG: KASAN: use-after-free in exfat_find_dir_entry+0x133b/0x15a0 BUG: unable to handle page fault for address: ffff88801a5fa0c2 Oops: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI RIP: 0010:exfat_find_dir_entry+0x1188/0x15a0 With this patch applied, the same instrumented harness completes cleanly under the same sanitizer stack. I have not reproduced a crash on an uninstrumented kernel under ordinary reclaim; the instrumented A/B establishes the lifetime violation and that the patch closes it, not an unaided triggerability claim.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63809", "url": "https://ubuntu.com/security/CVE-2026-63809", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: use kvfree() for replaced sysctl write buffer proc_sys_call_handler() allocates its temporary sysctl buffer with kvzalloc() and passes it to __cgroup_bpf_run_filter_sysctl(). Since kvzalloc() may fall back to vmalloc() for large allocations, freeing that buffer with kfree() is wrong and can corrupt memory. Use kvfree() to safely handle both kmalloc and kvzalloc()/vmalloc allocations. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in v7.1-rc5. Reproduced the bug based on v7.1-rc4 in a QEMU x86_64 guest booted with KASAN and CONFIG_FAILSLAB enabled. To exercise the replacement path, the test tree also included the accompanying fix for the stale ret == 1 check in __cgroup_bpf_run_filter_sysctl(). The reproducer confines failslab injections to the proc_sys_call_handler() range, uses stacktrace-depth=32, and injects fail-nth=1 while writing 8191 bytes to /proc/sys/kernel/domainname from a task in the target cgroup. Under that setup, fail-nth=1 triggered the fault: BUG: unable to handle page fault for address: ffffeb0200024d48 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 SMP KASAN NOPTI CPU: 2 UID: 0 PID: 209 Comm: repro_proc_sys_ Not tainted 7.1.0-rc4-00686-g97625979a5d4 PREEMPT(lazy) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 RIP: 0010:kfree+0x6e/0x510 ... Call Trace: ? __cgroup_bpf_run_filter_sysctl+0x626/0xc30 __cgroup_bpf_run_filter_sysctl+0x74d/0xc30 ? __pfx___cgroup_bpf_run_filter_sysctl+0x10/0x10 ? srso_return_thunk+0x5/0x5f ? __kvmalloc_node_noprof+0x345/0x870 ? proc_sys_call_handler+0x250/0x480 ? srso_return_thunk+0x5/0x5f proc_sys_call_handler+0x3a2/0x480 ? __pfx_proc_sys_call_handler+0x10/0x10 ? srso_return_thunk+0x5/0x5f ? selinux_file_permission+0x39f/0x500 ? srso_return_thunk+0x5/0x5f ? lock_is_held_type+0x9e/0x120 vfs_write+0x98e/0x1000 ... With this fix applied on top of the same test setup, rerunning the reproducer with fail-nth=1 yields no corresponding Oops reports.", "cve_priority": "high", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63812", "url": "https://ubuntu.com/security/CVE-2026-63812", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix incorrect FI_NO_EXTENT handling in __destroy_extent_node() When __destroy_extent_node() sets the inode flag FI_NO_EXTENT, it does not reset the length of the largest extent to 0 and update the inode folio. Since modifications to the extent tree are disallowed afterward, the cached largest extent may become stale. This can trigger the following error in xfstests generic/388: F2FS-fs (dm-0): sanity_check_extent_cache: inode (ino=1761) extent info [220057, 57, 6] is incorrect, run fsck to fix In the f2fs_drop_inode path, __destroy_extent_node() does not need to guarantee that et->node_cnt is 0, because concurrency with writeback is expected in this path, and writeback may update the extent cache. This patch reverts commit ed78aeebef05 (\"f2fs: fix node_cnt race between extent node destroy and writeback\"), and remove the unnecessary zero check of et->node_cnt.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63814", "url": "https://ubuntu.com/security/CVE-2026-63814", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: validate ACL entry sizes in f2fs_acl_from_disk() f2fs_acl_count() only validates the aggregate ACL xattr length. A malformed ACL can still place ACL_USER or ACL_GROUP in a slot that only contains struct f2fs_acl_entry_short bytes, and f2fs_acl_from_disk() then reads entry->e_id before verifying that a full entry fits. Require a short entry before reading e_tag and e_perm, and require a full entry before reading e_id for ACL_USER and ACL_GROUP. Return -EFSCORRUPTED from these new truncated-entry checks, while keeping the pre-existing -EINVAL paths unchanged. Validation reproduced this kernel report: KASAN slab-out-of-bounds in __f2fs_get_acl+0x6fb/0x7e0 RIP: 0033:0x7f4b835ea7aa The buggy address belongs to the object at ffff888114589960 which belongs to the cache kmalloc-8 of size 8 The buggy address is located 0 bytes to the right of allocated 8-byte region [ffff888114589960, ffff888114589968) Read of size 4 Call trace: dump_stack_lvl+0x66/0xa0 (?:?) print_report+0xce/0x630 (?:?) __f2fs_get_acl+0x6fb/0x7e0 (fs/f2fs/acl.c:169) srso_alias_return_thunk+0x5/0xfbef5 (?:?) __virt_addr_valid+0x224/0x430 (?:?) kasan_report+0xe0/0x110 (?:?) __f2fs_get_acl+0x5/0x7e0 (fs/f2fs/acl.c:169) __get_acl+0x281/0x380 (?:?) vfs_get_acl+0x10b/0x190 (?:?) do_get_acl+0x2a/0x410 (?:?) do_get_acl+0x9/0x410 (?:?) do_getxattr+0xe8/0x260 (?:?) filename_getxattr+0xd1/0x140 (?:?) do_getname+0x2d/0x2d0 (?:?) path_getxattrat+0x16c/0x200 (?:?) lock_release+0xc8/0x290 (?:?) cgroup_update_frozen+0x9d/0x320 (?:?) lockdep_hardirqs_on_prepare+0xea/0x1a0 (?:?) trace_hardirqs_on+0x1a/0x170 (?:?) _raw_spin_unlock_irq+0x28/0x50 (?:?) do_syscall_64+0x115/0x6a0 (arch/x86/entry/syscall_64.c:87) entry_SYSCALL_64_after_hwframe+0x77/0x7f (?:?)", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63817", "url": "https://ubuntu.com/security/CVE-2026-63817", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: validate compress cache inode only when enabled F2FS_COMPRESS_INO() uses NM_I(sbi)->max_nid as the synthetic inode number for the compressed page cache inode. That inode only exists when the compress_cache mount option is enabled. When compress_cache is disabled, max_nid is outside the valid inode range. A corrupted directory entry that points to ino == max_nid should therefore be rejected by f2fs_check_nid_range(). However, is_meta_ino() currently treats F2FS_COMPRESS_INO() as a meta inode unconditionally, so f2fs_iget() bypasses do_read_inode() and its nid range check, and instantiates a fake internal inode instead. Gate the compressed cache inode case on COMPRESS_CACHE, matching f2fs_init_compress_inode(). With compress_cache disabled, ino == max_nid now follows the normal inode path and is rejected as an out-of-range nid.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63821", "url": "https://ubuntu.com/security/CVE-2026-63821", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw88: usb: fix memory leaks on USB write failures When rtw_usb_write_port() fails to submit a USB Request Block (URB) (e.g., due to device disconnect or ENOMEM), the completion callback is never executed. Currently, the driver ignores the return value of rtw_usb_write_port() in rtw_usb_write_data() and rtw_usb_tx_agg_skb(). Because these functions rely on the completion callback to free the socket buffers (skbs) and the transaction control block (txcb), a submission failure results in: 1. A memory leak of the allocated skb in rtw_usb_write_data(). 2. A memory leak of the txcb structure and all aggregated skbs in rtw_usb_tx_agg_skb(). Fix this by checking the return value of rtw_usb_write_port(). If it fails, explicitly free the skb in rtw_usb_write_data(), and properly purge the tx_ack_queue and free the txcb in rtw_usb_tx_agg_skb(). The issue was discovered in practice during device disconnect/reconnect scenarios and memory pressure conditions. Tested by verifying normal TX operation continues after the fix without regressions.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63822", "url": "https://ubuntu.com/security/CVE-2026-63822", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix warning when unbinding If there is an error during some initialization related to firmware, the buffers dp->tx_ring[i].tx_status are released. However this is released again when the device is unbinded (ath11k_pci), and we get: WARNING: CPU: 0 PID: 6231 at mm/slub.c:4368 free_large_kmalloc+0x57/0x90 Call Trace: free_large_kmalloc ath11k_dp_free ath11k_core_deinit ath11k_pci_remove ... The issue is always reproducible from a VM because the MSI addressing initialization is failing. In order to fix the issue, just set the buffers to NULL after releasing in order to avoid the double free.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63823", "url": "https://ubuntu.com/security/CVE-2026-63823", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: keys: Pin request_key_auth payload in instantiate paths A: request_key() B: KEYCTL_INSTANTIATE_IOV ================ ========================= create auth key store rka in auth key wait for helper get auth key load rka from auth key copy user payload sleep on #PF helper completed detach and free rka destroy auth key wake up use rka->target_key **USE-AFTER-FREE** Give request_key_auth payloads a refcount. Take a payload reference while authkey->sem stabilizes the payload and revocation state. Hold that reference across the instantiate and reject paths. Drop the auth key owning reference from revoke and destroy. [jarkko: Replaced the first two paragraphs of text with an actual concurrency scenario.]", "cve_priority": "high", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63824", "url": "https://ubuntu.com/security/CVE-2026-63824", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KEYS: fix overflow in keyctl_pkey_params_get_2() The length for the internal output buffer is calculated incorrectly, which can result overflow when a too small buffer is provided. Fix the bug by allocating internal output with the size of the maximum length of the cryptographic primitive instead of caller provided size.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63826", "url": "https://ubuntu.com/security/CVE-2026-63826", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: fix use-after-free in store_modes() store_modes() replaces a framebuffer's modelist with modes from userspace. On success it frees the old modelist with fb_destroy_modelist(). Two fields still point into that freed list. One pointer is fb_display[i].mode, the mode a console is using. fbcon_new_modelist() moves these pointers to the new list. It only does so for consoles still mapped to the framebuffer. An unmapped console is skipped and keeps its stale pointer. Unbinding fbcon, for example, sets con2fb_map[i] to -1 but leaves fb_display[i].mode set. An FBIOPUT_VSCREENINFO ioctl with FB_ACTIVATE_INV_MODE later reaches fbcon_mode_deleted(). That function reads the stale fb_display[i].mode through fb_mode_is_equal(). The read is a use-after-free. The other pointer is fb_info->mode, the current mode. It is set through the mode sysfs attribute. store_modes() does not update fb_info->mode, so it is left pointing into the freed list. show_mode(), the attribute's read handler, dereferences the stale fb_info->mode through mode_string(). The read is a use-after-free. Clear both pointers before freeing the list. Commit a1f305893074 (\"fbcon: Set fb_display[i]->mode to NULL when the mode is released\") added the helper fbcon_delete_modelist(). It clears every fb_display[i].mode that points into a given list. So far it is called only from the unregister path. Call it from store_modes() too, and set fb_info->mode to NULL.", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-64254", "url": "https://ubuntu.com/security/CVE-2026-64254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NTB: epf: Avoid pci_iounmap() with offset when PEER_SPAD and CONFIG share BAR When BAR_PEER_SPAD and BAR_CONFIG share one PCI BAR, the module teardown path ends up calling pci_iounmap() on the same iomem with some offset, which is unnecessary and triggers a kernel warning like the following: Trying to vunmap() nonexistent vm area (0000000069a5ffe8) WARNING: mm/vmalloc.c:3470 at vunmap+0x58/0x68, CPU#5: modprobe/2937 [...] Call trace: vunmap+0x58/0x68 (P) iounmap+0x34/0x48 pci_iounmap+0x2c/0x40 ntb_epf_pci_remove+0x44/0x80 [ntb_hw_epf] pci_device_remove+0x48/0xf8 device_remove+0x50/0x88 device_release_driver_internal+0x1c8/0x228 driver_detach+0x50/0xb0 bus_remove_driver+0x74/0x100 driver_unregister+0x34/0x68 pci_unregister_driver+0x34/0xa0 ntb_epf_pci_driver_exit+0x14/0xfe0 [ntb_hw_epf] [...] Fix it by unmapping only when PEER_SPAD and CONFIG use difference bars.", "cve_priority": "medium", "cve_public_date": "2026-07-24 16:16:00 UTC" }, { "cve": "CVE-2026-63827", "url": "https://ubuntu.com/security/CVE-2026-63827", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: apparmor: fix use-after-free in rawdata dedup loop aa_replace_profiles() walks ns->rawdata_list to dedup the incoming policy blob against entries already attached to existing profiles. Per the kernel-doc on struct aa_loaddata, list membership does not hold a reference: profiles hold pcount, and when the last pcount drops, do_ploaddata_rmfs() is queued on a workqueue that takes ns->lock and removes the entry. Between dropping the last pcount and the workqueue running, an entry remains on the list with pcount == 0. aa_get_profile_loaddata() is an unconditional kref_get() on pcount, so when the dedup loop hits such an entry, refcount hardening reports refcount_t: addition on 0; use-after-free. inside aa_replace_profiles(), and the poisoned counter then trips \"saturated\" and \"underflow\" warnings on the subsequent uses of the same loaddata. Before commit a0b7091c4de4 (\"apparmor: fix race on rawdata dereference\") the dedup path used a get_unless_zero-style helper on a single counter, so the existing \"if (tmp)\" guard was meaningful. The split-refcount refactor introduced aa_get_profile_loaddata(), which has plain kref_get() semantics, and the guard quietly became a no-op. Introduce aa_get_profile_loaddata_not0(), matching the existing _not0 convention used by aa_get_profile_not0(), and use it for the rawdata_list dedup lookup so dying entries are skipped. Reproduced on x86_64 with v7.1-rc5 in QEMU+KVM running Ubuntu 24.04 + stress-ng 0.17.06: stress-ng --apparmor 1 --klog-check --timeout 60s Without this patch the three refcount_t warnings fire within a few seconds. With it the same 60 s run is clean. Coverage is a smoke-test only; a longer soak with CONFIG_KASAN, CONFIG_KCSAN and CONFIG_PROVE_LOCKING would be welcome from anyone with the cycles.", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63828", "url": "https://ubuntu.com/security/CVE-2026-63828", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: apparmor: mediate the implicit connect of TCP fast open sendmsg sendmsg()/sendto() with MSG_FASTOPEN is a combination of connect(2) and write(2): it opens the connection in the SYN. apparmor_socket_sendmsg() only checks AA_MAY_SEND, so a profile that grants send but denies connect lets a confined task open an outbound TCP/MPTCP connection that connect(2) would have refused, bypassing connect mediation. Mediate the implicit connect when MSG_FASTOPEN is set and a destination is supplied. Add it to apparmor_socket_sendmsg() (not the shared aa_sock_msg_perm() helper, which recvmsg also uses) and call aa_sk_perm() directly, mirroring the selinux and tomoyo fixes. sk_is_tcp() does not cover MPTCP fast open, so the SOCK_STREAM/IPPROTO_MPTCP arm is explicit.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63830", "url": "https://ubuntu.com/security/CVE-2026-63830", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: skmsg: preserve sg.copy across SG transforms The sk_msg sg.copy bitmap is part of the scatterlist entry ownership state. A set bit tells sk_msg_compute_data_pointers() not to expose the entry through writable BPF ctx->data. This protects entries backed by pages that are not private to the sk_msg, such as splice-backed file page-cache pages. Several sk_msg transform paths move, copy, split, or compact msg->sg.data[] entries without moving the matching sg.copy bit. This can make an externally backed entry arrive at a new slot with a clear copy bit. A later SK_MSG verdict can then expose sg_virt(sge) as writable ctx->data and BPF stores can modify the original page cache. Keep sg.copy synchronized with sg.data[] whenever entries are transferred, shifted, split, or copied into a new sk_msg. Clear the bit when an entry is replaced by a newly allocated private page or freed. This covers the BPF pull/push/pop helpers, sk_msg_shift_left/right(), sk_msg_xfer(), and tls_split_open_record(), including the partial tail entry created during TLS open-record splitting.", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63831", "url": "https://ubuntu.com/security/CVE-2026-63831", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mac802154: llsec: add skb_cow_data() before in-place crypto llsec_do_encrypt_unauth(), llsec_do_encrypt_auth(), llsec_do_decrypt_unauth(), and llsec_do_decrypt_auth() all perform in-place cryptographic transformations on skb data. They build a scatterlist with sg_init_one() pointing into the skb's linear data area and then pass the same scatterlist as both src and dst to the crypto API (e.g. crypto_skcipher_encrypt/decrypt, crypto_aead_encrypt/decrypt). On the RX path, __ieee802154_rx_handle_packet() clones the received skb before handing it to each subscriber via ieee802154_subif_frame(). The cloned skb shares the same underlying data buffer via reference counting. When llsec_do_decrypt() subsequently modifies this shared buffer in place, it corrupts data that other clones -- potentially belonging to other sockets or subsystems -- still reference. On the TX path, similar data sharing can occur when an skb's head has been cloned (skb_cloned() returns true). The fix is to call skb_cow_data() before performing any in-place crypto operation. skb_cow_data() ensures that the skb's data area is not shared: if the skb head is cloned or the data spans multiple fragments, it copies the data into a private buffer that can be safely modified in place. This is the same pattern used by: - ESP (net/ipv4/esp4.c, net/ipv6/esp6.c) - MACsec (drivers/net/macsec.c) - WireGuard (drivers/net/wireguard/receive.c) - TIPC (net/tipc/crypto.c) Without this guard, in-place crypto on shared skb data leads to: - Silent data corruption of other skb clones - Use-after-free when the crypto API scatterwalk writes through a page that has already been freed by another clone's kfree_skb() - Kernel crashes under concurrent 802.15.4 traffic with security enabled (KASAN/KMSAN reports slab-use-after-free) Found by 0sec (https://0sec.ai) using automated source analysis.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53361", "url": "https://ubuntu.com/security/CVE-2026-53361", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: af_unix: Set gc_in_progress to true in unix_gc(). Igor Ushakov reported that unix_gc() could run with gc_in_progress being false if the work is scheduled while running: Thread 1 Thread 2 Thread 3 -------- -------- -------- unix_schedule_gc() unix_schedule_gc() `- if (!gc_in_progress) `- if (!gc_in_progress) |- gc_in_progress = true | `- queue_work() | unix_gc() <----------------/ | | |- gc_in_progress = true ... `- queue_work() | | `- gc_in_progress = false | | unix_gc() <---------------------------------------------' | ... /* gc_in_progress == false */ | `- gc_in_progress = false unix_peek_fpl() relies on gc_in_progress not to confuse GC by MSG_PEEK. Let's set gc_in_progress to true in unix_gc().", "cve_priority": "medium", "cve_public_date": "2026-07-04 12:17:00 UTC" }, { "cve": "CVE-2026-63833", "url": "https://ubuntu.com/security/CVE-2026-63833", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: reject direct userspace writes to reserved $LX* xattrs NTFS3 uses $LXUID, $LXGID, $LXMOD and $LXDEV as internal WSL permission metadata and reloads them into i_uid, i_gid and i_mode from ntfs_get_wsl_perm(). Because the empty-prefix xattr handler also lets file owners call setxattr() on these names directly, an unprivileged writer on a writable ntfs3 mount can plant root ownership and S_ISUID on their own file and gain euid 0 after inode reload. Reject direct userspace writes to the reserved $LX* names. Internal ntfs3 metadata updates are unchanged because ntfs_save_wsl_perm() writes them via ntfs_set_ea() directly. [almaz.alexandrovich@paragon-software.com: added an additional check for non privileged users]", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53366", "url": "https://ubuntu.com/security/CVE-2026-53366", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: account for fraggap on the paged allocation path In __ip_append_data(), when the paged-allocation branch is taken, alloclen and pagedlen are computed as \talloclen = fragheaderlen + transhdrlen; \tpagedlen = datalen - transhdrlen; datalen already includes fraggap, but the fraggap bytes carried over from the previous skb are copied into the new skb's linear area at offset transhdrlen by the subsequent skb_copy_and_csum_bits(). The linear area is therefore undersized by fraggap bytes while pagedlen is overstated by the same amount. The non-paged branch sets alloclen to fraglen, which already accounts for fraggap because datalen does. Bring the paged branch in line by adding fraggap to alloclen and subtracting it from pagedlen. After this adjustment, copy no longer collapses to -fraggap on the paged path, so remove the stale comment describing that old arithmetic.", "cve_priority": "medium", "cve_public_date": "2026-07-16 06:16:00 UTC" }, { "cve": "CVE-2026-53362", "url": "https://ubuntu.com/security/CVE-2026-53362", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: account for fraggap on the paged allocation path In __ip6_append_data(), when the paged-allocation branch is taken (MSG_MORE / NETIF_F_SG / large fraglen), alloclen and pagedlen are computed as \talloclen = fragheaderlen + transhdrlen; \tpagedlen = datalen - transhdrlen; datalen already includes fraggap (datalen = length + fraggap). When fraggap is non-zero, this is not the first skb and transhdrlen is zero. The fraggap bytes carried over from the previous skb are copied just past the fragment headers in the new skb's linear area. The linear area is therefore undersized by fraggap bytes while pagedlen is overstated by the same amount, and the copy writes past skb->end into the trailing skb_shared_info. An unprivileged user can trigger this via a UDPv6 socket using MSG_MORE together with MSG_SPLICE_PAGES. The bad accounting was introduced by commit 773ba4fe9104 (\"ipv6: avoid partial copy for zc\"). Before commit ce650a166335 (\"udp6: Fix __ip6_append_data()'s handling of MSG_SPLICE_PAGES\"), the negative copy value caused -EINVAL to be returned. That later commit allowed MSG_SPLICE_PAGES to proceed in this case, making the corruption triggerable. The non-paged branch sets alloclen to fraglen, which already accounts for fraggap because datalen does. Bring the paged branch in line by adding fraggap to alloclen and subtracting it from pagedlen. After this adjustment, copy no longer collapses to -fraggap on the paged path, so remove the stale comment describing that old arithmetic. Since a negative copy is no longer expected for a valid MSG_SPLICE_PAGES case, remove the MSG_SPLICE_PAGES exception from the negative copy check.", "cve_priority": "high", "cve_public_date": "2026-07-04 12:17:00 UTC" }, { "cve": "CVE-2026-63834", "url": "https://ubuntu.com/security/CVE-2026-63834", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: tp_meter: restrict number of unacked list entries When the unacked_list is unbound, an attacker could send messages with small lengths and appropriated seqno + gaps to force the receiver to allocate more and more unacked_list entries. And the end either causing an out-of-memory situation or increase the management overhead for the (large) list that significant portions of CPU cycles are wasted in searching through the list. When limiting the list to a specific number, it is important to still correctly add a new entry to the list. But if the list became larger than the limit, the last entry of the list (with the highest seqno) must be dropped to still allow the earlier seqnos to finish and therefore to continue the process. Otherwise, the process might get stuck with too high seqnos which are not handled by batadv_tp_ack_unordered().", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63835", "url": "https://ubuntu.com/security/CVE-2026-63835", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: v: prevent OGM aggregation on disabled hardif When an interface gets disabled, the worker is correctly disabled by batadv_hardif_disable_interface() -> ... -> batadv_v_ogm_iface_disable(). In this process, the skb aggr_list is also freed. But batadv_v_ogm_send_meshif() can still queue new skbs (via batadv_v_ogm_queue_on_if()) to the aggr_list. This will only stop after all cores can no longer find the RCU protected list of hard interfaces. These queued skbs will never be freed or consumed by batadv_v_ogm_aggr_work. The batadv_v_ogm_iface_disable() function must block batadv_v_ogm_queue_on_if() to avoid leak of skbs.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63836", "url": "https://ubuntu.com/security/CVE-2026-63836", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: tp_meter: avoid divide-by-zero for dec_cwnd The cwnd is always MSS <= cwnd <= 0x20000000. But the calculation in batadv_tp_update_cwnd() assumes unsigned 32 bit arithmetics. ((mss * 8) ** 2) / (cwnd * 8) In case cwnd is actually 0x20000000, it will be shifted by 3 bit to the left end up at 0x100000000 or U32_MAX + 1. It will therefore wrap around and be 0 - resulting in: ((mss * 8) ** 2) / 0 This is of course invalid and cannot be calculated. The calculation should must be simplified to avoid this overflow: (mss ** 2) * 8 / cwnd It will keep the precision enhancement from the scaling (by 8) but avoid the overflow in the divisor. In theory, there could still be an overflow in the dividend. It is at the moment fixed to BATADV_TP_PLEN in batadv_tp_recv_ack() - so it is not an imminent problem. But allowing it to use the whole u32 bit range, would mean that it can still use up to 67 bits. To keep this calculation safe for 32 bit arithmetic, mss must never use more than floor((32 - 3) / 2) bits - or in other words: must never be larger than 16383.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63807", "url": "https://ubuntu.com/security/CVE-2026-63807", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86/mmu: Ensure hugepage is in by slot before checking max mapping level When recovering hugepages in the shadow MMU, verify that the base gfn of the shadow page is actually contained within the target memslot, *before* querying the max mapping level given the shadow page's gfn. Failure to pre-check the validity of the gfn can lead to an out-of-bounds access to the slot's lpage_info (which typically manifests as a host #PF because the lpage_info is vmalloc'd) if the guest creates a hugepage mapping (in its PTEs) that extends \"below\" the bounds of a memslot. When faulting in memory for a guest, and the size of the guest mapping is greater than KVM's (current) max mapping, then KVM will create a \"direct\" shadow page (direct in that there are no gPTEs to shadow, and so the target gfn is a direct calculation given the base gfn of the shadow page). The hugepage recovery flow looks for such direct shadow pages, as forcing 4KiB mappings when dirty logging generates the guest > host mapping size case. When the 4KiB restriction is lifted, then KVM can replace the shadow page with a hugepage. But if KVM originally used a smaller mapping than the guest because the range of memory covered by the guest hugepage exceeds the bounds of a memslot, then KVM will link a direct shadow page with a gfn that is outside the bounds of the memslot being used to fault in memory. The rmap entry added for the leaf mapping is correct and within bounds, but the gfn of the leaf SPTE's parent shadow page will be out of bounds. BUG: unable to handle page fault for address: ffffc90000806ffc #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 100000067 P4D 100000067 PUD 1002a7067 PMD 10612f067 PTE 0 Oops: Oops: 0000 [#1] SMP CPU: 13 UID: 1000 PID: 757 Comm: mmu_stress_test Not tainted 7.1.0-rc1-48ce1e26eace-x86_pir_to_irr_comments-vm #341 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:kvm_mmu_max_mapping_level+0x79/0x2b0 [kvm] Call Trace: kvm_mmu_recover_huge_pages+0x21b/0x320 [kvm] kvm_set_memslot+0x1ee/0x590 [kvm] kvm_set_memory_region.part.0+0x3a1/0x4d0 [kvm] kvm_vm_ioctl+0x9bf/0x15d0 [kvm] __x64_sys_ioctl+0x8a/0xd0 do_syscall_64+0xb7/0xbb0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f21c0f1a9bf Don't bother pre-checking the bounds of the potential hugepage, i.e. don't check that e.g. sp->gfn + KVM_PAGES_PER_HPAGE(sp->role.level + 1) is also within the memslot, as the checks performed by kvm_mmu_max_mapping_level() are a superset of the basic bounds checks. I.e. pre-checking the full range would be a dubious micro-optimization.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53381", "url": "https://ubuntu.com/security/CVE-2026-53381", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtiofs: fix UAF on submount umount iput() called from fuse_release_end() can Oops if the super block has already been destroyed. Normally this is prevented by waiting for num_waiting to go down to zero before commencing with super block shutdown. This only works, however, for the last submount instance, as the wait counter is per connection, not per superblock. Revert to using synchronous release requests for the auto_submounts case, which is virtiofs only at this time.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53382", "url": "https://ubuntu.com/security/CVE-2026-53382", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: vidtv: fix NULL pointer dereference in vidtv_mux_push_si syzbot reported a general protection fault in vidtv_psi_ts_psi_write_into [1]. vidtv_mux_get_pid_ctx() can return NULL, but vidtv_mux_push_si() does not check for this before dereferencing the returned pointer to access the continuity counter. This leads to a general protection fault when accessing a near-NULL address. The root cause is that vidtv_mux_pid_ctx_init() does not check the return value of vidtv_mux_create_pid_ctx_once() for PMT section PIDs. If the allocation fails, the PID context is never created, but init returns success. The subsequent vidtv_mux_push_si() call then gets NULL from vidtv_mux_get_pid_ctx() and crashes. Fix both the root cause (add error check in vidtv_mux_pid_ctx_init for PMT PIDs) and add defensive NULL checks in vidtv_mux_push_si for all vidtv_mux_get_pid_ctx() calls. [1] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] Workqueue: events vidtv_mux_tick RIP: 0010:vidtv_psi_ts_psi_write_into+0x54a/0xbc0 drivers/media/test-drivers/vidtv/vidtv_psi.c:197 Call Trace: vidtv_psi_table_header_write_into drivers/media/test-drivers/vidtv/vidtv_psi.c:799 [inline] vidtv_psi_pmt_write_into+0x3b2/0xa70 drivers/media/test-drivers/vidtv/vidtv_psi.c:1231 vidtv_mux_push_si+0x932/0xe80 drivers/media/test-drivers/vidtv/vidtv_mux.c:196 vidtv_mux_tick+0xe9b/0x1480 drivers/media/test-drivers/vidtv/vidtv_mux.c:408", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53383", "url": "https://ubuntu.com/security/CVE-2026-53383", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: reject non-VALID session in compound request branch smb2_check_user_session() takes a shortcut for any operation that is not the first in a COMPOUND request: it reuses work->sess (the session bound by the first operation) and validates only the SessionId, then returns \"valid\". It never re-checks work->sess->state == SMB2_SESSION_VALID, and a SessionId of 0xFFFFFFFFFFFFFFFF (ULLONG_MAX, the MS-SMB2 related-operation value) skips even the id comparison. The standalone path (ksmbd_session_lookup_all() plus the SESSION_SETUP state machine) does enforce the VALID state; the compound branch bypasses all of it. A SESSION_SETUP carrying only an NTLM Type-1 (NtLmNegotiate) blob publishes a fresh SMB2_SESSION_IN_PROGRESS session whose sess->user is still NULL (->user is assigned later, by ntlm_authenticate()). Used as operation 1 of a COMPOUND with operation 2 = TREE_CONNECT (related, SessionId=ULLONG_MAX, \\\\host\\IPC$), the tree-connect then runs on that IN_PROGRESS session and reaches ksmbd_ipc_tree_connect_request(), which dereferences user_name(sess->user) with sess->user == NULL (transport_ipc.c:687/701/704) -> remote NULL-pointer dereference and a kernel Oops that wedges the ksmbd worker for all clients. Reject any non-first compound operation that lands on a session which is not SMB2_SESSION_VALID, mirroring the validity the standalone lookup path enforces. SESSION_SETUP itself legitimately runs on an IN_PROGRESS session, but it is never carried as a non-first compound operation, so multi-leg authentication is unaffected by this check.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53385", "url": "https://ubuntu.com/security/CVE-2026-53385", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vc_screen: fix null-ptr-deref in vcs_notifier() during concurrent vcs_write A KASAN null-ptr-deref was observed in vcs_notifier(): BUG: KASAN: null-ptr-deref in vcs_notifier+0x98/0x130 Read of size 2 at addr qmp_cmd_name: qmp_capabilities, arguments: {} The issue is a race condition in vcs_write(). When the console_lock is temporarily dropped (to copy data from userspace), the vc_data pointer obtained from vcs_vc() may become stale. After re-acquiring the lock, vcs_vc() is called again to re-validate the pointer. If the vc has been deallocated in the meantime, vcs_vc() returns NULL, and the while loop breaks (with written > 0). However, after the loop, vcs_scr_updated(vc) is still called with the now-NULL vc pointer, leading to a null pointer dereference in the notifier chain (vcs_notifier dereferences param->vc). Fix this by adding a NULL check for vc before calling vcs_scr_updated().", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53388", "url": "https://ubuntu.com/security/CVE-2026-53388", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: re-lock request before replacing page cache folio fuse_try_move_folio() unlocks the request on entry but does not re-lock it on the success path. This means fuse_chan_abort() can end the request and free the fuse_io_args (eg fuse_readpages_end()) while the subsequent copy chain logic after fuse_try_move_folio() accesses the fuse_io_args, leading to use-after-free issues. Fix this by calling lock_request() before replace_page_cache_folio(). This ensures the request is locked on the success path which will prevent the fuse_io_args from being freed while the later copying logic runs, and also ensures that the ap->folios[i]->mapping is never null since ap->folios[i] will always point to the newfolio after replace_page_cache_folio().", "cve_priority": "high", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53157", "url": "https://ubuntu.com/security/CVE-2026-53157", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: phonet: free phonet_device after RCU grace period phonet_device_destroy() removes a phonet_device from the per-net device list with list_del_rcu(), but frees it immediately. RCU readers walking the same list can still hold a pointer to the object after it has been removed, leading to a slab-use-after-free. Use kfree_rcu(), matching the lifetime rule already used by phonet_address_del() for the same object type.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53163", "url": "https://ubuntu.com/security/CVE-2026-53163", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: locking/rtmutex: Skip remove_waiter() when waiter is not enqueued syzbot triggered the following splat in remove_waiter() via FUTEX_CMP_REQUEUE_PI: KASAN: null-ptr-deref in range [0x0000000000000a88-0x0000000000000a8f] class_raw_spinlock_constructor remove_waiter+0x159/0x1200 kernel/locking/rtmutex.c:1561 rt_mutex_start_proxy_lock+0x103/0x120 futex_requeue+0x10e4/0x20d0 __x64_sys_futex+0x34f/0x4d0 task_blocks_on_rt_mutex() does not arm the waiter upon deadlock detection, leaving waiter->task nil, where 3bfdc63936dd (\"rtmutex: Use waiter::task instead of current in remove_waiter()\") made this fatal. Furthermore, rt_mutex_start_proxy_lock() should not be calling into remove_waiter() upon a successfully grabbing the rtmutex. 1a1fb985f2e2 (\"futex: Handle early deadlock return correctly\"), moved the remove_waiter() out of __rt_mutex_start_proxy_lock() (where 'ret' was only ever 0 or < 0) into the wrapper. Tighten this check to account for try_to_take_rt_mutex().", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2025-23131", "url": "https://ubuntu.com/security/CVE-2025-23131", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dlm: prevent NPD when writing a positive value to event_done do_uevent returns the value written to event_done. In case it is a positive value, new_lockspace would undo all the work, and lockspace would not be set. __dlm_new_lockspace, however, would treat that positive value as a success due to commit 8511a2728ab8 (\"dlm: fix use count with multiple joins\"). Down the line, device_create_lockspace would pass that NULL lockspace to dlm_find_lockspace_local, leading to a NULL pointer dereference. Treating such positive values as successes prevents the problem. Given this has been broken for so long, this is unlikely to break userspace expectations.", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:16:00 UTC" }, { "cve": "CVE-2026-46252", "url": "https://ubuntu.com/security/CVE-2026-46252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regulator: core: fix locking in regulator_resolve_supply() error path If late enabling of a supply regulator fails in regulator_resolve_supply(), the code currently triggers a lockdep warning: WARNING: drivers/regulator/core.c:2649 at _regulator_put+0x80/0xa0, CPU#6: kworker/u32:4/596 ... Call trace: _regulator_put+0x80/0xa0 (P) regulator_resolve_supply+0x7cc/0xbe0 regulator_register_resolve_supply+0x28/0xb8 as the regulator_list_mutex must be held when calling _regulator_put(). To solve this, simply switch to using regulator_put(). While at it, we should also make sure that no concurrent access happens to our rdev while we clear out the supply pointer. Add appropriate locking to ensure that. While the code in question will be removed altogether in a follow-up commit, I believe it is still beneficial to have this corrected before removal for future reference.", "cve_priority": "low", "cve_public_date": "2026-06-03 18:16:00 UTC" }, { "cve": "CVE-2026-52928", "url": "https://ubuntu.com/security/CVE-2026-52928", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: af_unix: Reject SIOCATMARK on non-stream sockets SIOCATMARK reports whether the receive queue is at the urgent mark for MSG_OOB. In AF_UNIX, MSG_OOB is supported only for SOCK_STREAM sockets. SOCK_DGRAM and SOCK_SEQPACKET reject MSG_OOB in sendmsg() and recvmsg(), so they should not support SIOCATMARK either. Return -EOPNOTSUPP for non-stream sockets before checking the receive queue.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-43010", "url": "https://ubuntu.com/security/CVE-2026-43010", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Reject sleepable kprobe_multi programs at attach time kprobe.multi programs run in atomic/RCU context and cannot sleep. However, bpf_kprobe_multi_link_attach() did not validate whether the program being attached had the sleepable flag set, allowing sleepable helpers such as bpf_copy_from_user() to be invoked from a non-sleepable context. This causes a \"sleeping function called from invalid context\" splat: BUG: sleeping function called from invalid context at ./include/linux/uaccess.h:169 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1787, name: sudo preempt_count: 1, expected: 0 RCU nest depth: 2, expected: 0 Fix this by rejecting sleepable programs early in bpf_kprobe_multi_link_attach(), before any further processing.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-53325", "url": "https://ubuntu.com/security/CVE-2026-53325", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: agp/amd64: Fix broken error propagation in agp_amd64_probe() A NULL pointer dereference was observed in the AMD64 AGP driver when running in a virtualized environment (e.g. qemu/kvm) without a physical AMD northbridge. The crash occurs in amd64_fetch_size() when attempting to dereference the pointer returned by node_to_amd_nb(0). The root cause of this crash is broken error propagation in agp_amd64_probe(): When no AMD northbridges are found, cache_nbs() correctly returns -ENODEV. However, the probe function erroneously checks the return value against exactly -1, rather than < 0. As a result, the hardware absence error is masked, allowing the driver to improperly proceed with initialization. It eventually calls agp_add_bridge(), which invokes amd64_fetch_size(). Since the hardware does not exist, node_to_amd_nb(0) returns NULL, leading to a General Protection Fault (GPF) when accessing its ->misc member. Fix the issue by correcting the error check in agp_amd64_probe() to abort properly when cache_nbs() returns any negative error code. This prevents the driver from erroneously proceeding without hardware, thereby avoiding the subsequent NULL pointer dereference at its source.", "cve_priority": "medium", "cve_public_date": "2026-06-29 06:16:00 UTC" }, { "cve": "CVE-2026-64188", "url": "https://ubuntu.com/security/CVE-2026-64188", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qualcomm: rmnet: fix endpoint use-after-free in rmnet_dellink() rmnet_dellink() removes the endpoint from the hash table with hlist_del_init_rcu() and then immediately frees it with kfree(). However, RCU readers on the receive path (rmnet_rx_handler -> __rmnet_map_ingress_handler) may still hold a reference to the endpoint and dereference ep->egress_dev after the memory has been freed. The endpoint is a kmalloc-32 object, and the stale read at offset 8 corresponds to the egress_dev pointer. BUG: unable to handle page fault for address: ffffffffde942eef Oops: 0002 [#1] SMP NOPTI CPU: 1 UID: 0 PID: 137 Comm: poc_write Not tainted 7.0.0+ #4 PREEMPTLAZY RIP: 0010:rmnet_vnd_rx_fixup (rmnet_vnd.c:27) Call Trace: __rmnet_map_ingress_handler (rmnet_handlers.c:48 rmnet_handlers.c:101) rmnet_rx_handler (rmnet_handlers.c:129 rmnet_handlers.c:235) __netif_receive_skb_core.constprop.0 (net/core/dev.c:6096) __netif_receive_skb_one_core (net/core/dev.c:6208) netif_receive_skb (net/core/dev.c:6467) tun_get_user (drivers/net/tun.c:1955) tun_chr_write_iter (drivers/net/tun.c:2003) vfs_write (fs/read_write.c:688) ksys_write (fs/read_write.c:740) Add an rcu_head field to struct rmnet_endpoint and replace kfree() with kfree_rcu() so the endpoint memory remains valid through the RCU grace period. Also remove the rmnet_vnd_dellink() call and inline only the nr_rmnet_devs decrement, since rmnet_vnd_dellink() would set ep->egress_dev to NULL during the grace period, creating a data race with lockless readers.", "cve_priority": "high", "cve_public_date": "2026-07-20 17:18:00 UTC" }, { "cve": "CVE-2026-64191", "url": "https://ubuntu.com/security/CVE-2026-64191", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: stub: Reject I2C block transfers with invalid length The I2C_SMBUS_I2C_BLOCK_DATA case in stub_xfer() uses data->block[0] as the transfer length. The existing check only clamps it to avoid overrunning the chip->words[256] register array, but does not validate it against I2C_SMBUS_BLOCK_MAX (32), which is the limit of the union i2c_smbus_data.block buffer (34 bytes total). The driver is a development/test tool (CONFIG_I2C_STUB=m, not built by default) that must be loaded with a chip_addr= parameter. A local user with access to /dev/i2c-* can issue an I2C_SMBUS ioctl with I2C_SMBUS_I2C_BLOCK_DATA and data->block[0] > 32, causing stub_xfer() to read or write past the end of the union i2c_smbus_data.block buffer: BUG: KASAN: stack-out-of-bounds in stub_xfer (drivers/i2c/i2c-stub.c:223) Read of size 1 at addr ffff88800abcfd92 by task exploit/81 Call Trace: stub_xfer (drivers/i2c/i2c-stub.c:223) __i2c_smbus_xfer (drivers/i2c/i2c-core-smbus.c:593) i2c_smbus_xfer (drivers/i2c/i2c-core-smbus.c:536) i2cdev_ioctl_smbus (drivers/i2c/i2c-dev.c:391) i2cdev_ioctl (drivers/i2c/i2c-dev.c:478) __x64_sys_ioctl (fs/ioctl.c:583) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) The bug exists because i2c-stub implements .smbus_xfer directly, bypassing the I2C_SMBUS_BLOCK_MAX validation in i2c_smbus_xfer_emulated(). The I2C_SMBUS_BLOCK_DATA case in the same function correctly validates against I2C_SMBUS_BLOCK_MAX, but the I2C_SMBUS_I2C_BLOCK_DATA case does not. Fix by rejecting transfers with data->block[0] == 0 or data->block[0] > I2C_SMBUS_BLOCK_MAX with -EINVAL, consistent with both the I2C_SMBUS_BLOCK_DATA case in the same function and the I2C_SMBUS_I2C_BLOCK_DATA validation in i2c_smbus_xfer_emulated().", "cve_priority": "high", "cve_public_date": "2026-07-20 17:18:00 UTC" }, { "cve": "CVE-2026-53327", "url": "https://ubuntu.com/security/CVE-2026-53327", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: debugobjects: Do not fill_pool() if pi_blocked_on On RT enabled kernels, fill_pool() ends up calling rtlock_lock(), which asserts if current::pi_blocked_on is set, because a task can obviously only block on one lock as otherwise the priority inheritenace chain gets corrupted. Prevent this by expanding the conditional to take current::pi_blocked_on into account.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-52909", "url": "https://ubuntu.com/security/CVE-2026-52909", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ip6_vti: set netns_immutable on the fallback device. john1988 and Noam Rathaus reported that vti6_init_net() does not set the netns_immutable flag on the per-netns fallback tunnel device (ip6_vti0). Other similar tunnel drivers (like ip6_tunnel, sit, ip6_gre, and ip_tunnel) correctly set this flag during their fallback device initialization to prevent them from being moved to another network namespace.", "cve_priority": "high", "cve_public_date": "2026-06-19 15:16:00 UTC" }, { "cve": "CVE-2026-53167", "url": "https://ubuntu.com/security/CVE-2026-53167", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: limit FUSE_NOTIFY_RETRIEVE to uptodate folios FUSE_NOTIFY_RETRIEVE must be limited to uptodate folios; !uptodate folios can contain uninitialized data. Since FUSE_NOTIFY_RETRIEVE is intended to only return data that is already in the page cache and not wait for data from the FUSE daemon, treat !uptodate folios as if they weren't present. This only has security impact on systems that don't enable automatic zero-initialization of all page allocations via CONFIG_INIT_ON_ALLOC_DEFAULT_ON or init_on_alloc=1.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" } ], "launchpad_bugs_fixed": [ 2168142, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2071590, 2160493, 2162917, 2165140, 2165732, 2167237, 2167237, 2166995, 2166995, 2166995, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192 ], "changes": [ { "cves": [ { "cve": "CVE-2026-68371", "url": "https://ubuntu.com/security/CVE-2026-68371", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: musb: omap2430: Do not put borrowed of_node in probe omap2430_probe() stores pdev->dev.of_node in a local np variable. This is a borrowed pointer and the probe function does not take a reference to it. The success and error paths nevertheless call of_node_put(np). This drops a reference that is owned by the platform device, and can leave pdev->dev.of_node with an unbalanced reference count. Do not put the borrowed platform device node from omap2430_probe(). References taken for the child MUSB device are handled by the device core, and the ctrl-module phandle reference is still released separately.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-72130", "url": "https://ubuntu.com/security/CVE-2026-72130", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-auth: reject short AUTH_RECEIVE buffers nvmet_execute_auth_receive() trusts the AUTH_RECEIVE allocation length after checking only that it is nonzero and matches the transfer length. In the SUCCESS1 and FAILURE1/default states, that lets a remote NVMe-oF initiator reach the fixed-size DH-HMAC-CHAP response builders with a kmalloc() buffer shorter than the response, so nvmet_auth_success1() and nvmet_auth_failure1() write past the allocation; both only WARN_ON the short length and then format the message anyway. Impact: A remote NVMe-oF initiator with access to an auth-enabled target can trigger a 16-byte heap out-of-bounds write via a one-byte AUTH_RECEIVE allocation length. Compute the minimum response length for the current DH-HMAC-CHAP step in nvmet_auth_receive_data_len() and report a zero data length when the host-supplied allocation length is shorter, so the existing zero-length check in nvmet_execute_auth_receive() rejects the command before any builder runs. The SUCCESS1 minimum is sizeof(struct nvmf_auth_dhchap_success1_data) plus the HMAC hash length, because the response hash is written into the rval[] flexible-array tail, so the minimum is state dependent rather than a flat sizeof. CHALLENGE keeps its existing variable-length guard in nvmet_auth_challenge(). This is reachable only when in-band DH-HMAC-CHAP authentication is configured on the target.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72168", "url": "https://ubuntu.com/security/CVE-2026-72168", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: maps: vmu-flash: fix fault in unaligned fixup Use kzalloc_obj() / kzalloc_objs() to allocate the memcard structs, instead of kmalloc_obj() / kmalloc_objs() to prevent access to uninitialized data. Fixes runtime error: Fault in unaligned fixup: 0000 [#1] at mtd_get_fact_prot_info.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72213", "url": "https://ubuntu.com/security/CVE-2026-72213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: fix hugetlb cgroup rsvd charge/uncharge mismatch In alloc_hugetlb_folio(), a single h_cg pointer is used for both the rsvd and non-rsvd hugetlb cgroup charges. When map_chg is set, hugetlb_cgroup_charge_cgroup_rsvd() stores the charged cgroup in h_cg, but the immediately following hugetlb_cgroup_charge_cgroup() overwrites h_cg with the non-rsvd cgroup pointer. As a result, hugetlb_cgroup_commit_charge_rsvd() stores the wrong (non-rsvd) cgroup pointer into the folio's rsvd slot. When the folio is later freed, free_huge_folio() unconditionally calls both hugetlb_cgroup_uncharge_folio() and hugetlb_cgroup_uncharge_folio_rsvd(). The rsvd uncharge reads back the wrong cgroup from the folio and decrements a counter that was never charged for that cgroup, causing a page_counter underflow: page_counter underflow: -512 nr_pages=512 WARNING: mm/page_counter.c:61 at page_counter_cancel Fix this by introducing a separate h_cg_rsvd pointer exclusively for the rsvd charge path, keeping the rsvd and non-rsvd charges fully independent through their charge, commit, and error uncharge paths.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72244", "url": "https://ubuntu.com/security/CVE-2026-72244", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpu/buddy: bail out of try_harder when alignment cannot be honoured The try_harder contiguous fallback could return a range whose start offset did not match the caller's min_block_size. When a candidate's start is misaligned, realign it: free the misaligned run and reallocate exactly @size at the next lower min_block_size boundary. This keeps the returned size unchanged with no surplus to trim, and rejects the request only when no aligned candidate fits. v2: align misaligned candidates down to min_block_size instead of bailing out, for both the RHS and LHS paths (Matthew).", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-68129", "url": "https://ubuntu.com/security/CVE-2026-68129", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gve: fix Rx queue stall on alloc failure When the system is under extreme memory pressure, page allocations can fail during the Rx buffer refill loop. If the number of buffers posted to hardware falls below a critical low threshold and the refill loop exits due to allocation failures, the queue can stall: 1. The device drops incoming packets because there are no descriptors. 2. Since no packets are processed, no Rx completions are generated. 3. Because no completions occur, NAPI is never scheduled, preventing the refill loop from running again even after memory is freed. This results in a permanent queue stall. Resolve this by introducing a starvation recovery timer for each Rx queue. If the number of buffers posted to hardware falls below a critical low threshold, start a timer to periodically reschedule NAPI. Once NAPI runs and successfully refills the queue above the threshold, the timer is not rescheduled. The threshold is set to 32 because a single maximum-sized Receive Segment Coalescing (RSC) packet can consume up to 19 descriptors in the Rx path. Lower thresholds (such as 8 or 16) would be insufficient to process a complete maximum-sized RSC packet, risking packet drops or unexpected hardware behavior under memory pressure. Setting the threshold to 32 guarantees a safe margin to handle at least one full RSC packet.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-53078", "url": "https://ubuntu.com/security/CVE-2026-53078", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix same-register dst/src OOB read and pointer leak in sock_ops When a BPF sock_ops program accesses ctx fields with dst_reg == src_reg, the SOCK_OPS_GET_SK() and SOCK_OPS_GET_FIELD() macros fail to zero the destination register in the !fullsock / !locked_tcp_sock path. Both macros borrow a temporary register to check is_fullsock / is_locked_tcp_sock when dst_reg == src_reg, because dst_reg holds the ctx pointer. When the check is false (e.g., TCP_NEW_SYN_RECV state with a request_sock), dst_reg should be zeroed but is not, leaving the stale ctx pointer: - SOCK_OPS_GET_SK: dst_reg retains the ctx pointer, passes NULL checks as PTR_TO_SOCKET_OR_NULL, and can be used as a bogus socket pointer, leading to stack-out-of-bounds access in helpers like bpf_skc_to_tcp6_sock(). - SOCK_OPS_GET_FIELD: dst_reg retains the ctx pointer which the verifier believes is a SCALAR_VALUE, leaking a kernel pointer. Fix both macros by: - Changing JMP_A(1) to JMP_A(2) in the fullsock path to skip the added instruction. - Adding BPF_MOV64_IMM(si->dst_reg, 0) after the temp register restore in the !fullsock path, placed after the restore because dst_reg == src_reg means we need src_reg intact to read ctx->temp.", "cve_priority": "low", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-68119", "url": "https://ubuntu.com/security/CVE-2026-68119", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: initialize standalone TCP-AO response padding tcp_v4_send_ack() and tcp_v6_send_response() construct standalone TCP responses with TCP-AO options. The option length carries the actual MAC length, but the TCP header length includes the option rounded up to a four-byte boundary. tcp_ao_hash_hdr() writes the MAC only. Thus, when the MAC length is not four-byte aligned, the one to three bytes after the MAC are left uninitialized and may be transmitted. For the normal TCP-AO hashing mode, those bytes also have to be initialized before computing the MAC. Initialize only the alignment padding in the TCP-AO branches, before hashing the header. Use TCPOPT_NOP, as in the normal TCP-AO output path. This avoids adding work to non-AO TCP responses while preserving a valid authenticated header.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68136", "url": "https://ubuntu.com/security/CVE-2026-68136", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: gro: fix double aggregation of flush-marked skbs Commit 0ab03f353d36 (\"net-gro: Fix GRO flush when receiving a GSO packet.\") added a flush check to skb_gro_receive(), but skb_gro_receive_list() lacks the same validation. As a result, packets marked with NAPI_GRO_CB(skb)->flush may still be re-aggregated. This allows already-GRO'd packets with existing frag_list to be re-aggregated into a new GRO session, corrupting the frag_list chain structure. When skb_segment() attempts to unpack these malformed packets, it encounters invalid state and triggers a kernel panic. Scenario (Tethering/Device forwarding): 1. Driver: Generated aggregated packet P1 via LRO with frag_list 2. Dev A: Receives aggregated fraglist packet and flush flag set 3. Dev A: Re-enters GRO, skb_gro_receive_list() is called 4. Missing flush check allows re-aggregation despite flush flag 5. Frag_list chain becomes corrupted (loops or dangling refs) 6. Dev B: TX path calls skb_segment(), crashes on corrupted frag_list Root cause in skb_segment(): The check at line ~4891: if (hsize <= 0 && i >= nfrags && skb_headlen(list_skb) && (skb_headlen(list_skb) == len || sg)) { When frag_list is corrupted by double aggregation, when list_skb is a NULL pointer from skb->next, skb_headlen(list_skb) dereference NULL/corrupted pointers occurs. Call Trace: skb_headlen(NULL skb) skb_segment tcp_gso_segment tcp4_gso_segment inet_gso_segment skb_mac_gso_segment __skb_gso_segment skb_gso_segment validate_xmit_skb validate_xmit_skb_list sch_direct_xmit qdisc_restart __qdisc_run qdisc_run net_tx_action Fix: Add NAPI_GRO_CB(skb)->flush validation to the early-return check in skb_gro_receive_list(), matching the defensive programming pattern of skb_gro_receive().", "cve_priority": "high", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68139", "url": "https://ubuntu.com/security/CVE-2026-68139", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Use sender devcom for MPV master-up After PCIe DPC recovery, mlx5 reloads the affected functions and replays multiport affiliation events. In the reported failure, the first relevant device error was: pcieport 0000:10:01.1: DPC: containment event pcieport 0000:10:01.1: PCIe Bus Error: severity=Uncorrected (Fatal) pcieport 0000:10:01.1: [ 5] SDES (First) mlx5 recovered the PCI functions and resumed 0000:11:00.1. During that resume, RDMA multiport binding replayed MLX5_DRIVER_EVENT_AFFILIATION_DONE and mlx5e sent MPV_DEVCOM_MASTER_UP. The host then panicked with: BUG: kernel NULL pointer dereference, address: 0000000000000010 RIP: mlx5_devcom_comp_set_ready+0x5/0x40 [mlx5_core] RDI: 0000000000000000 Call trace included: mlx5_devcom_comp_set_ready mlx5e_devcom_event_mpv mlx5_devcom_send_event mlx5_ib_bind_slave_port mlx5r_mp_probe mlx5_pci_resume MPV devcom registration publishes mlx5e private data to the component peer list before mlx5e_devcom_init_mpv() stores the returned component device in priv->devcom. A concurrent master-up event can therefore reach a peer whose private data is visible but whose priv->devcom backpointer is still NULL. MPV_DEVCOM_MASTER_UP already carries the sender/master mlx5e private data as event_data. The ready bit is stored on the shared devcom component, not on an individual peer. Use the sender devcom when marking the MPV component ready. This preserves the readiness transition while avoiding a NULL dereference of the peer devcom pointer during affiliation replay after PCI error recovery.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68145", "url": "https://ubuntu.com/security/CVE-2026-68145", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iomap: fix out-of-bounds bitmap_set() with zero-length range ifs_set_range_dirty() and ifs_set_range_uptodate() compute last_blk as (off + len - 1) >> i_blkbits. When off is 0 and len is 0, the unsigned subtraction underflows to SIZE_MAX, producing a huge last_blk and nr_blks value that causes bitmap_set() to write far beyond the ifs->state allocation. Regarding ifs_set_range_uptodate(), it is temporarily safe because len cannot be passed in as 0. However, for ifs_set_range_dirty() this is reachable from __iomap_write_end(): when copy_folio_from_iter_atomic() returns 0 (e.g. user buffer fault) and the folio is already uptodate, the guard at the top of __iomap_write_end() does not trigger because !folio_test_uptodate() is false, and iomap_set_range_dirty() is called with copied == 0. Add a !len guard to both functions before the computation, so that a zero-length range is a no-op.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68161", "url": "https://ubuntu.com/security/CVE-2026-68161", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: close UDP tunnel sockets during netns teardown proc_sctp_do_udp_port() starts per-net SCTP UDP tunneling sockets when net.sctp.udp_port is set, and stops/restarts them when the sysctl value changes. The netns exit path does not stop these sockets, so a namespace can be torn down while its SCTP UDP tunnel sockets are still installed. Close the UDP tunnel sockets from sctp_ctrlsock_exit() after unregistering the per-net sysctl table. This prevents new sysctl writes from racing in while the sockets are being released, and closes the sockets before the control socket is destroyed.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68162", "url": "https://ubuntu.com/security/CVE-2026-68162", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: avoid auth_enable sysctl UAF during netns teardown proc_sctp_do_auth() updates the SCTP control socket after changing net.sctp.auth_enable. The handler gets the per-net SCTP state from ctl->data, so an already opened sysctl file can still target a network namespace while that namespace is being torn down. SCTP previously registered its per-net sysctls from sctp_defaults_init(), while the control socket is created later from sctp_ctrlsock_init(). This exposed a window during initialization where auth_enable was writable before net->sctp.ctl_sock existed, and a teardown window where auth_enable stayed writable after inet_ctl_sock_destroy() had released the control socket. Move the per-net SCTP sysctl registration into sctp_ctrlsock_init() after sctp_ctl_sock_init() succeeds, and unregister the sysctl table before destroying the control socket in sctp_ctrlsock_exit(). If sysctl registration fails after the control socket was created, destroy the control socket in the same init path. Make sctp_sysctl_net_unregister() tolerate a missing header and clear the saved pointer so init-error and exit paths can safely share the unregister helper.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68178", "url": "https://ubuntu.com/security/CVE-2026-68178", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: nsm: pin the module while the device is open misc_open() installs a misc driver's file operations with fops_get(), which pins file_operations::owner before replacing the file's f_op. The NSM misc device leaves nsm_dev_fops.owner unset, so opening /dev/nsm does not take a module reference on the nsm driver. If the driver is built as a module, an open file descriptor can therefore survive rmmod of the module that provides its ioctl callbacks. A later ioctl through that descriptor can call into unloaded module text. Set nsm_dev_fops.owner to THIS_MODULE so the misc core holds the module while any /dev/nsm file descriptor is open, matching the lifetime expectation for the installed file operations.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68179", "url": "https://ubuntu.com/security/CVE-2026-68179", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: misc: nsm: only unlock nsm_dev on post-lock error paths nsm_dev_ioctl() jumps to the common out label even when the initial copy_from_user() fails before nsm->lock has been taken. The error path then blindly unlocks a mutex that was never acquired. This issue was found by our static analysis tool and then manually reviewed against the current tree. The grounded PoC kept the miscdevice ioctl entry and the pre-lock copy_from_user(&raw, argp, _IOC_SIZE(cmd)) failure path by issuing NSM_IOCTL_RAW with an invalid user pointer. That failure reaches the shared out label before mutex_lock(&nsm->lock). Lockdep reported: WARNING: bad unlock balance detected! exploit/193 is trying to release lock (&global_nsm.lock) at: nsm_dev_ioctl+0x5f/0xcf [vuln_msv] but there are no more locks to release! no locks held by exploit/193. Return immediately on the pre-lock copy_from_user() failure and keep the common unlock label for the post-lock paths only.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68183", "url": "https://ubuntu.com/security/CVE-2026-68183", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: stratix10-svc: fix memory leaks and list corruption bugs Fix a memory leak when gen_pool_alloc() fails by freeing pmem on the error path. Switch pmem allocation from devm_kzalloc() to kzalloc() with explicit kfree() in the free path to match its list-managed lifetime. Remove the erroneous list_del(&svc_data_mem) which corrupted the list head on failed lookups.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68193", "url": "https://ubuntu.com/security/CVE-2026-68193", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7925: drop TXRX_NOTIFY on non-mmio buses PKT_TYPE_TXRX_NOTIFY is an mmio-only event, but mt7925_rx_check() and mt7925_queue_rx_skb() dispatch it to mt7925_mac_tx_free() on every bus. mt7925_mac_tx_free() cleans the DMA tx queues with mt76_queue_tx_cleanup(), which calls queue_ops->tx_cleanup(). Only the mmio queue ops implement that callback; on USB it is NULL, so a TXRX_NOTIFY there calls a NULL pointer in the RX worker: BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:0x0 Call Trace: mt7925_mac_tx_free+0x58/0x350 [mt7925_common] mt7925_rx_check+0xe2/0x130 [mt7925_common] mt76u_rx_worker+0x1b9/0x620 [mt76_usb] Drop the event on non-mmio buses via mt76_is_mmio(), as in commit 5683e1488aa9 (\"wifi: mt76: connac: do not check WED status for non-mmio devices\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68203", "url": "https://ubuntu.com/security/CVE-2026-68203", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: vivid: fix cleanup bugs in vivid_init() When platform_device_register() fails in vivid_init(), the embedded struct device in vivid_pdev has already been initialized by device_initialize(), but the failure path jumps to free_output_strings without dropping the device reference for the current platform device: vivid_init() -> platform_device_register(&vivid_pdev) -> device_initialize(&vivid_pdev.dev) -> setup_pdev_dma_masks(&vivid_pdev) -> platform_device_add(&vivid_pdev) This leads to a reference leak when platform_device_register() fails. Fix this by calling platform_device_put() before jumping to the common cleanup path. Also, the unreg_driver label incorrectly calls platform_driver_register() instead of platform_driver_unregister(), which breaks cleanup when workqueue creation fails after successful driver registration. Fix that as well. The reference leak was identified by a static analysis tool I developed and confirmed by manual review. The incorrect cleanup call was found during code inspection.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68205", "url": "https://ubuntu.com/security/CVE-2026-68205", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: v4l2-fwnode: Fix subdev owner overwritten in v4l2_async_register_subdev_sensor() The v4l2 helper v4l2_async_register_subdev_sensor() calls v4l2_async_register_subdev(), which is a macro that expands to __v4l2_async_register_subdev(sd,THIS_MODULE). Since the macro is expanded inside v4l2-fwnode.c, THIS_MODULE resolves to the v4l2-fwnode module rather than the sensor driver module that originally set sd->owner. When v4l2-fwnode is built-in, THIS_MODULE evaluates to NULL, which then overwrites the sensor driver's owner with NULL. This causes the problem that the sensor module's reference count is never incremented during async registration, so the module can be removed while the subdevice is still in use by a notifier (e.g., a CSI-2 receiver bridge driver). Fix this by renaming v4l2_async_register_subdev_sensor() to __v4l2_async_register_subdev_sensor() with an added explicit module argument and introducing a wrapper macro: #define v4l2_async_register_subdev_sensor(sd) \\ __v4l2_async_register_subdev_sensor(sd, THIS_MODULE) This ensures the sensor driver module is properly referenced even when the sensor driver does not init the owner field before calling v4l2_async_register_subdev_sensor() and prevents premature module removal.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68221", "url": "https://ubuntu.com/security/CVE-2026-68221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: nuvoton: npcm-video: fix memory leaks in probe and remove npcm_video_probe() allocates the npcm_video structure with kzalloc_obj() but never frees it on any probe error path or in npcm_video_remove(), leaking the allocation on every failed probe and every normal unbind. Additionally, when npcm_video_setup_video() fails, the reserved memory association established by of_reserved_mem_device_init() in npcm_video_init() is not released, leaking the rmem_assigned_device entry on the global list. Fix both by adding kfree(video) to all probe error paths and to npcm_video_remove(), and adding the missing of_reserved_mem_device_release() call when npcm_video_setup_video() fails.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68225", "url": "https://ubuntu.com/security/CVE-2026-68225", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: i2c: alvium: fix critical pointer access in alvium_ctrl_init The current implementation of alvium_ctrl_init creates several controls in function alvium_ctrl_init and uses the returned pointer without check. That can cause write access over NULL-pointer for several controls. The reworked code checks the pointers before adding flags.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68228", "url": "https://ubuntu.com/security/CVE-2026-68228", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: chips-media: wave5: Move src_buf Removal to finish_encode During encoder processing, there is a case where the IRQ response could return the buffer back to userspace via v4l2_m2m_buf_done call. In this time, userspace could queue up this same buffer before start_encode removes the index from the ready queue. This would then lead to a case where the buffer in the ready queue could be a self loop due to the WRITE_ONCE(prev->next, new) call in __list_add. When __list_del is finally called, the loop is already made so nothing points back to ready queue list head and pointers are poisoned. A buffer should not be marked as DONE before the buffer is removed from m2m ready queue. Move removal entirely to finish_encode.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68235", "url": "https://ubuntu.com/security/CVE-2026-68235", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: dce100: skip non-DP stream encoders for DP MST On DCE8-class ASICs (e.g. Bonaire), the resource pool contains digital DIG stream encoders plus one analog DAC encoder. When assigning a stream encoder for a second DisplayPort MST stream, if the preferred digital encoder is already acquired, dce100_find_first_free_match_stream_enc_for_link() falls back to the first free pool entry. That entry may be the analog encoder, whose funcs table lacks DP hooks such as dp_set_stream_attribute. The subsequent atomic commit then dereferences NULL function pointers in link_set_dpms_on() and crashes. Skip encoders without dp_set_stream_attribute when the stream uses a DP signal (including MST). Use dc_is_dp_signal(stream->signal) for the MST fallback path instead of checking only the link connector signal. Tested on: - GPU: AMD Radeon R7 260X (Bonaire / DCE8) - Board: Supermicro C9X299-PG300 - Setup: DP MST daisy chain, hotplug second monitor or have it connected on boot - Kernel: 7.1.3 (issue observed since 6.19) - Result: kernel oops without patch; dual monitors stable with patch (cherry picked from commit 28ec64943e3ee4d9b8d30cea61e380f1429953a8)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68247", "url": "https://ubuntu.com/security/CVE-2026-68247", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/bios: range check LFP Data Block panel_type2 While the panel_type from LFP Data Block is range checked, panel_type2 is not. Add a few helpers for range checking, and use them to not only check panel_type2, but also improve clarity and correctness in the panel type selection. Discovered using AI-assisted static analysis confirmed by Intel Product Security. v2: - Fix commit message typo (MichaÅ‚) - Add is_panel_type_pnp() (Ville) (cherry picked from commit c9ebe5d2f25729d6cfbbb1235d640bf67f9275df)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68260", "url": "https://ubuntu.com/security/CVE-2026-68260", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: acquire vm_ctx->lock before mapping memory to GPU VM The drm gpuvm code doesn't protect find operation against map operation, and the driver needs to ensure a map operation shouldn't happen when a find operation is in progress. In some cases a find operation will be in progress when doing map/unmap operations, and the find operation will do a NULL pointer dereference. An example of the stack trace of such NULL dereference is shown below: ``` Unable to handle kernel access to user memory without uaccess routines at virtual address 0000000000000010 [] drm_gpuva_find+0x28/0x6c [drm_gpuvm] [] pvr_vm_unmap+0x34/0x68 [powervr] [] pvr_ioctl_vm_unmap+0x2e/0x50 [powervr] [] drm_ioctl_kernel+0x8e/0xdc [] drm_ioctl+0x1be/0x3e0 [] __riscv_sys_ioctl+0xba/0xc4 [] do_trap_ecall_u+0x23e/0x3f4 [] handle_exception+0x168/0x174 ``` As all occurences of drm_gpuva_find*() are already guarded by vm_ctx->lock, make pvr_vm_map() to acquire this lock to prevent disturbing any find operation. This fixes the NULL deference problem in drm_gpuva_find*().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68261", "url": "https://ubuntu.com/security/CVE-2026-68261", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: fix error checking of pvr_vm_context_lookup() Since pvr_vm_context_lookup() returns either NULL or a pointer, then stop using IS_ERR() for checking the return value. Using IS_ERR() leads to the kernel oops reported below. It can be reproduced by passing an invalid VM context handle from userspace to the DRM_IOCTL_PVR_CREATE_CONTEXT ioctl. [ 92.733119] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000148 [ 92.742042] Mem abort info: [ 92.744890] ESR = 0x0000000096000004 [ 92.748686] EC = 0x25: DABT (current EL), IL = 32 bits [ 92.754020] SET = 0, FnV = 0 [ 92.757154] EA = 0, S1PTW = 0 [ 92.760337] FSC = 0x04: level 0 translation fault [ 92.765243] Data abort info: [ 92.768129] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 92.773626] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 92.778763] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 92.784098] user pgtable: 4k pages, 48-bit VAs, pgdp=000000088ed23000 [ 92.790550] [0000000000000148] pgd=0000000000000000, p4d=0000000000000000 [ 92.797381] Internal error: Oops: 0000000096000004 [#1] SMP [ 92.803027] Modules linked in: powervr [ 92.852533] CPU: 0 UID: 0 PID: 409 Comm: triangle Not tainted 7.1.0-rc5-g98b46e693b91 #1 PREEMPT [ 92.861385] Hardware name: Texas Instruments AM68 SK (DT) [ 92.866766] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 92.873709] pc : pvr_vm_get_fw_mem_context+0x0/0xc [powervr] [ 92.879376] lr : pvr_queue_create+0x26c/0x440 [powervr] [ 92.884595] sp : ffff8000837fbb00 [ 92.887895] x29: ffff8000837fbb60 x28: 0000000000000000 x27: ffff8000837fbce8 [ 92.895015] x26: ffff000807f61a40 x25: ffff000807f61a00 x24: ffff000807f64400 [ 92.902135] x23: ffff00080a5ab000 x22: ffff800079b24730 x21: ffff000807f61800 [ 92.909254] x20: ffff00080999e680 x19: 0000000000000000 x18: 0000000000000000 [ 92.916373] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000001 [ 92.923492] x14: 0000000000000000 x13: 0000000000000002 x12: ffff80008145b298 [ 92.930611] x11: ffff8000844e5000 x10: ffff80008165a130 x9 : 0000000000000100 [ 92.937730] x8 : 0000000000000001 x7 : ffff0008076b27e0 x6 : ffff00080ec43b7c [ 92.944850] x5 : ffff00080ec43b78 x4 : 0000000000000000 x3 : ffff00080999e680 [ 92.951968] x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 [ 92.959088] Call trace: [ 92.961521] pvr_vm_get_fw_mem_context+0x0/0xc [powervr] (P) [ 92.967173] pvr_context_create+0x190/0x410 [powervr] [ 92.972218] pvr_ioctl_create_context+0x44/0x8c [powervr] [ 92.977608] drm_ioctl_kernel+0xbc/0x124 [drm] [ 92.982127] drm_ioctl+0x1f8/0x4dc [drm] [ 92.986098] __arm64_sys_ioctl+0xac/0x104 [ 92.990102] invoke_syscall+0x54/0x10c [ 92.993842] el0_svc_common.constprop.0+0x40/0xe0 [ 92.998532] do_el0_svc+0x1c/0x28 [ 93.001835] el0_svc+0x38/0x11c [ 93.004969] el0t_64_sync_handler+0xa0/0xe4 [ 93.009139] el0t_64_sync+0x198/0x19c [ 93.012792] Code: aa1703e0 d2800014 95cb0ba4 17ffffe8 (f940a400) [ 93.018869] ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68262", "url": "https://ubuntu.com/security/CVE-2026-68262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: Fix user array stride in pvr_set_uobj_array() pvr_set_uobj_array() copies an array of kernel objects to a userspace array whose element size is described by out->stride. When out->stride is different from the kernel object size, the slow path advances the userspace pointer by the kernel object size and the kernel pointer by the userspace stride. This reverses the intended layout. For larger userspace strides, later copies read from the wrong kernel addresses. For smaller userspace strides, later copies are written at the wrong userspace offsets. The padding clear is also done only for the first element instead of the padding area for each element. Advance the userspace pointer by out->stride and the kernel pointer by obj_size, and clear per-element padding while the current userspace pointer is still available.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68263", "url": "https://ubuntu.com/security/CVE-2026-68263", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: Fix double call to drm_sched_entity_fini() Call sequence of double call: pvr_context_destroy   pvr_context_kill_queues     pvr_queue_kill       drm_sched_entity_destroy         drm_sched_entity_fini // here   pvr_context_put     kref_put(..., pvr_context_release)       pvr_context_destroy_queues         pvr_queue_destroy           drm_sched_entity_fini // here Call to drm_sched_entity_destroy() from pvr_context_kill_queues() calls drm_sched_entity_flush() + drm_sched_entity_fini(). drm_sched_entity_flush() ensures all pending jobs are completed and drm_sched_entity_fini() ensures no further submission is allowed as per expectation from pvr_context_kill_queues(). Double call to drm_sched_entity_fini() is misuse of the API so keep call only in pvr_context_create() failure path. Stack trace for issue with addition of refcounting for DRM entity stats in commit fd177135f0e6 (\"drm/sched: Account entity GPU time\"): [ 789.490527] ------------[ cut here ]------------ [ 789.490559] refcount_t: underflow; use-after-free. [ 789.490657] WARNING: lib/refcount.c:28 at refcount_warn_saturate+0xf4/0x144, CPU#0: kworker/u16:1/440 [ 789.490695] Modules linked in: powervr drm_gpuvm drm_exec gpu_sched drm_shmem_helper xhci_plat_hcd xhci_hcd dwc3 usbcore usb_common snd_soc_simple_card snd_soc_simple_card_utils sa2ul sha512 sha256 dwc3_am62 sha1 authenc rti_wdt libsha512 at24 sch_fq_codel fuse dm_mod ipv6 [ 789.490798] CPU: 0 UID: 0 PID: 440 Comm: kworker/u16:1 Not tainted 7.0.0-rc7-02049-g5e2c0700091b #22 PREEMPT [ 789.490809] Hardware name: Texas Instruments AM625 SK (DT) [ 789.490815] Workqueue: powervr-sched pvr_queue_fence_release_work [powervr] [ 789.490868] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 789.490876] pc : refcount_warn_saturate+0xf4/0x144 [ 789.490884] lr : refcount_warn_saturate+0xf4/0x144 [ 789.490892] sp : ffff8000822cbcc0 [ 789.490895] x29: ffff8000822cbcc0 x28: 0000000000000000 x27: 0000000000000000 [ 789.490909] x26: 0000000000000000 x25: ffff800081b1e338 x24: ffff000004541405 [ 789.490922] x23: ffff000004bea950 x22: ffff00000042e400 x21: ffff000007123e30 [ 789.490935] x20: ffff000007123000 x19: ffff000007a80d50 x18: fffffffffffe7768 [ 789.490948] x17: 74736574202c6e6f x16: 697461746e656d65 x15: ffff800081b269f0 [ 789.490962] x14: 0000000000000030 x13: ffff800081b26a70 x12: 0000000000000211 [ 789.490975] x11: 00000000000000c0 x10: 0000000000000b50 x9 : ffff8000822cbb30 [ 789.490988] x8 : ffff0000014e7bb0 x7 : ffff00007725e780 x6 : 0000000372a05f49 [ 789.491001] x5 : 0000000000000000 x4 : 0000000000000001 x3 : 0000000000000010 [ 789.491013] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000014e7000 [ 789.491027] Call trace: [ 789.491032] refcount_warn_saturate+0xf4/0x144 (P) [ 789.491043] drm_sched_entity_fini+0x164/0x18c [gpu_sched] [ 789.491081] pvr_queue_destroy+0x64/0x134 [powervr] [ 789.491110] pvr_context_destroy_queues+0x34/0x64 [powervr] [ 789.491138] pvr_context_release+0x70/0xac [powervr] [ 789.491166] pvr_context_put.part.0+0x5c/0x7c [powervr] [ 789.491193] pvr_context_put+0x14/0x24 [powervr] [ 789.491221] pvr_queue_fence_release_work+0x20/0x38 [powervr] [ 789.491249] process_one_work+0x160/0x4c4 [ 789.491264] worker_thread+0x188/0x310 [ 789.491276] kthread+0x130/0x13c [ 789.491287] ret_from_fork+0x10/0x20 [ 789.491300] ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68437", "url": "https://ubuntu.com/security/CVE-2026-68437", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: Fit paired fragment job in the correct CCCB For geometry jobs with a paired fragment job, at the moment, the DRM scheduler's prepare_job() callback: - checks for internal (driver) dependencies for the geometry job; - calls into pvr_queue_get_paired_frag_job_dep() to check for external dependencies for the fragment job (the two jobs are submitted together but the common scheduler code doesn't know about it, so this needs to be done at this point in time); - calls into the prepare_job() callback again, but for the fragment job, to check its internal dependencies as well, passing the fragment job's drm_sched_job and the geometry job's drm_sched_entity / pvr_queue. The problem with the last step is that pvr_queue_prepare_job() doesn't always take the mismatched fragment job and geometry queue into account, in particular when checking whether there is space for the fragment command to be submitted, so the code ends up checking for space in the geometry (i.e. wrong) CCCB. The rest of the nested prepare_job() callback happens to work fine at the moment as the other internal dependencies are not relevant for a paired fragment job. Move the initialisation of a paired fragment job's done fence and CCCB fence to pvr_queue_get_paired_frag_job_dep(), inferring the correct queue from the fragment job itself. This fixes cases where prepare_job() wrongly assumed that there was enough space for a paired fragment job in its own CCCB, unblocking run_job(), which then returned early without writing the full sequence of commands to the CCCB. The above lead to kernel warnings such as the following and potentially job timeouts (depending on waiters on the missing commands): [ 552.421075] WARNING: drivers/gpu/drm/imagination/pvr_cccb.c:178 at pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr], CPU#2: kworker/u16:5/63 [ 552.421230] Modules linked in: [ 552.421592] CPU: 2 UID: 0 PID: 63 Comm: kworker/u16:5 Tainted: G W 7.0.0-rc2-gc5d053e4dccb #39 PREEMPT [ 552.421625] Tainted: [W]=WARN [ 552.421637] Hardware name: Texas Instruments AM625 SK (DT) [ 552.421655] Workqueue: powervr-sched drm_sched_run_job_work [gpu_sched] [ 552.421744] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 552.421766] pc : pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr] [ 552.421850] lr : pvr_queue_submit_job_to_cccb+0x57c/0xa74 [powervr] [ 552.421923] sp : ffff800084c47650 [ 552.421936] x29: ffff800084c47740 x28: 0000000000000df8 x27: ffff800088a77000 [ 552.421979] x26: 0000000000000030 x25: ffff800084c47680 x24: 0000000000001000 [ 552.422017] x23: ffff800084c47820 x22: 1ffff00010988ecc x21: 0000000000000008 [ 552.422055] x20: 0000000000000208 x19: ffff000006ad5a88 x18: 0000000000000000 [ 552.422093] x17: 0000000020020000 x16: 0000000000020000 x15: 0000000000000000 [ 552.422130] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 [ 552.422167] x11: 000000000000f2f2 x10: 00000000f3000000 x9 : 00000000f3f3f3f3 [ 552.422204] x8 : 00000000f2f2f200 x7 : ffff700010988ecc x6 : 0000000000000008 [ 552.422241] x5 : 0000000000000000 x4 : 1ffff0001114ee00 x3 : 0000000000000000 [ 552.422278] x2 : 0000000000000007 x1 : 0000000000000fff x0 : 000000000000002f [ 552.422316] Call trace: [ 552.422330] pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr] (P) [ 552.422411] pvr_queue_submit_job_to_cccb+0x57c/0xa74 [powervr] [ 552.422486] pvr_queue_run_job+0x3a4/0x990 [powervr] [ 552.422562] drm_sched_run_job_work+0x580/0xd48 [gpu_sched] [ 552.422623] process_one_work+0x520/0x1288 [ 552.422657] worker_thread+0x3f0/0xb3c [ 552.422679] kthread+0x334/0x3d8 [ 552.422706] ret_from_fork+0x10/0x20", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68281", "url": "https://ubuntu.com/security/CVE-2026-68281", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: Count paired job fence as dependency in prepare_job() The DRM scheduler's prepare_job() callback counts the remaining non-signaled native dependencies for a job, preventing job submission until those (plus job data and fence update) can fit in the job queue's CCCB. This means checking which dependencies can be waited upon in the firmware, i.e. whether they are backed by a UFO object, i.e. whether their drm_sched_fence::parent has been assigned to a pvr_queue_fence::base fence. That happens when the job owning the fence is submitted to the firmware. Paired geometry and fragment jobs are submitted at the same time, which means the dependency between them can't be checked this way before submission. Update job_count_remaining_native_deps() to take into account the dependency between paired jobs. This fixes cases where prepare_job() underestimated the space left in an almost full fragment CCCB, wrongly unblocking run_job(), which then returned early without writing the full sequence of commands to the CCCB. The above lead to kernel warnings such as the following and potentially job timeouts (depending on waiters on the missing commands): [ 375.702979] WARNING: drivers/gpu/drm/imagination/pvr_cccb.c:178 at pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr], CPU#1: kworker/u16:3/47 [ 375.703160] Modules linked in: [ 375.703571] CPU: 1 UID: 0 PID: 47 Comm: kworker/u16:3 Tainted: G W 7.0.0-rc2-g817eb6b11ad5 #40 PREEMPT [ 375.703613] Tainted: [W]=WARN [ 375.703627] Hardware name: Texas Instruments AM625 SK (DT) [ 375.703645] Workqueue: powervr-sched drm_sched_run_job_work [gpu_sched] [ 375.703741] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 375.703764] pc : pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr] [ 375.703847] lr : pvr_queue_submit_job_to_cccb+0x578/0xa70 [powervr] [ 375.703921] sp : ffff800084a97650 [ 375.703934] x29: ffff800084a97740 x28: 0000000000000958 x27: ffff80008565d000 [ 375.703979] x26: 0000000000000030 x25: ffff800084a97680 x24: 0000000000001000 [ 375.704017] x23: ffff800084a97820 x22: 1ffff00010952ecc x21: 0000000000000008 [ 375.704056] x20: 00000000000006a8 x19: ffff00002ff7da88 x18: 0000000000000000 [ 375.704093] x17: 0000000020020000 x16: 0000000000020000 x15: 0000000000000000 [ 375.704132] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 [ 375.704168] x11: 000000000000f2f2 x10: 00000000f3000000 x9 : 00000000f3f3f3f3 [ 375.704206] x8 : 00000000f2f2f200 x7 : ffff700010952ecc x6 : 0000000000000008 [ 375.704243] x5 : 0000000000000000 x4 : 1ffff00010acba00 x3 : 0000000000000000 [ 375.704279] x2 : 0000000000000007 x1 : 0000000000000fff x0 : 000000000000002f [ 375.704317] Call trace: [ 375.704331] pvr_cccb_write_command_with_header+0x2c4/0x330 [powervr] (P) [ 375.704411] pvr_queue_submit_job_to_cccb+0x578/0xa70 [powervr] [ 375.704487] pvr_queue_run_job+0x3a4/0x990 [powervr] [ 375.704562] drm_sched_run_job_work+0x580/0xd48 [gpu_sched] [ 375.704623] process_one_work+0x520/0x1288 [ 375.704658] worker_thread+0x3f0/0xb3c [ 375.704680] kthread+0x334/0x3d8 [ 375.704706] ret_from_fork+0x10/0x20 [ 375.704736] ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68290", "url": "https://ubuntu.com/security/CVE-2026-68290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rds: tcp: unregister sysctl before tearing down listen socket rds_tcp_exit_net() frees the per-netns RDS TCP listen socket via rds_tcp_kill_sock() before unregistering the per-netns sysctl table. Since rds_tcp_skbuf_handler() derives the netns from rtn->rds_tcp_listen_sock->sk, a concurrent sysctl write can race with netns teardown and dereference the freed socket/sk. KASAN reports the race as: BUG: KASAN: slab-use-after-free in rds_tcp_skbuf_handler+0x2aa/0x2e0 rds_tcp_skbuf_handler net/rds/tcp.c:721 proc_sys_call_handler fs/proc/proc_sysctl.c vfs_write fs/read_write.c __x64_sys_pwrite64 fs/read_write.c Fix this by unregistering the RDS TCP sysctl table before calling rds_tcp_kill_sock(). unregister_net_sysctl_table() prevents new sysctl handlers from starting and waits for in-flight handlers to finish, so the listen socket can then be released safely. The fix was tested against the linked reproducer.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68293", "url": "https://ubuntu.com/security/CVE-2026-68293", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix MCIA register buffer overflow on 32 dword reads The MCIA register can return up to 32 dwords (128 bytes) when the device advertises the mcia_32dwords capability, but struct mlx5_ifc_mcia_reg_bits only defines dword_0..11, leaving room for just 12 dwords (48 bytes) of data. mlx5_query_mcia() clamps the read size to mlx5_mcia_max_bytes() and then memcpy()s that many bytes out of the register, potentially reading past the end of the 'out' buffer. On kernels built with FORTIFY_SOURCE this is caught as a buffer overflow while reading the module EEPROM via ethtool: detected buffer overflow in memcpy kernel BUG at lib/string_helpers.c:1048! RIP: 0010:fortify_panic+0x13/0x20 Call Trace: mlx5_query_mcia.isra.0+0x200/0x210 [mlx5_core] mlx5_query_module_eeprom_by_page+0x4a/0xa0 [mlx5_core] mlx5e_get_module_eeprom_by_page+0xbb/0x120 [mlx5_core] eeprom_prepare_data+0xf3/0x170 ethnl_default_doit+0xf1/0x3b0 Extend the mcia_reg layout to 32 dwords.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68439", "url": "https://ubuntu.com/security/CVE-2026-68439", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7925: fix possible NULL-pointer deref in mt7925_mcu_bss_he_tlv() mt76_connac_get_he_phy_cap routine can theoretically return NULL so check cap pointer before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68314", "url": "https://ubuntu.com/security/CVE-2026-68314", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mctp i3c: clean up notifier and buses if driver register fails mctp_i3c_mod_init() registers the I3C bus notifier and then walks the existing buses with i3c_for_each_bus_locked(mctp_i3c_bus_add_new, NULL) before registering the I3C device driver. If i3c_driver_register() fails, the function returns the error directly, leaving the notifier registered and every mctp_i3c_bus object created for the existing buses allocated. The notifier is left pointing into the module that failed to load and the bus list is leaked. Mirror the module exit path on this failure: unregister the notifier and tear down the buses that were added before returning the error. This issue was identified during our ongoing static-analysis research while reviewing kernel code.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68318", "url": "https://ubuntu.com/security/CVE-2026-68318", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pds_core: fix use-after-free on workqueue during remove In pdsc_remove(), the workqueue is destroyed before pdsc_teardown() is called. This ordering allows two paths to queue work on the destroyed workqueue: 1. If pdsc_teardown() -> pdsc_devcmd_reset() times out, the error path in pdsc_devcmd_locked() queues health_work. 2. A NotifyQ event can trigger the ISR and queue work before free_irq() is called in pdsc_teardown(). Fix by moving destroy_workqueue() after pdsc_teardown() so the workqueue outlives every queuer; destroy_workqueue() then flushes any work still pending. Draining the queued work also requires ordering the teardown so the resources that work touches are freed last: - In pdsc_qcq_free(), after freeing the interrupt, cancel_work_sync() the queue's work and only then clear qcq->intx, so pdsc_process_adminq()'s read of qcq->intx for interrupt-credit return cannot race with the clear. - Free adminqcq before notifyqcq: the shared adminq ISR is released when adminqcq is freed, and the adminq work accesses notifyqcq, so both must be stopped before notifyqcq is freed.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68319", "url": "https://ubuntu.com/security/CVE-2026-68319", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pds_core: fix deadlock between reset thread and remove pci_reset_function() acquires device_lock before performing the reset. pdsc_remove() is called by the PCI core with device_lock already held. If pdsc_pci_reset_thread() is running when pdsc_remove() is called, destroy_workqueue() will block waiting for the work to complete, while the work is blocked waiting for device_lock - deadlock. Use pci_try_reset_function() which uses pci_dev_trylock() internally. This acquires both the device lock and the PCI config access lock without blocking - if either lock is contended, it returns -EAGAIN immediately. This avoids the deadlock while also ensuring proper config space access serialization during the reset. The pci_dev_get/put calls are also removed as they were unnecessary - the driver-owned workqueue is destroyed in pdsc_remove(), guaranteeing the work completes before remove returns. The PCI core holds its reference to pci_dev throughout the entire unbind sequence.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68346", "url": "https://ubuntu.com/security/CVE-2026-68346", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: hda: cs35l41: validate and free ACPI mute object cs35l41_get_acpi_mute_state() evaluates a _DSM method to get the ACPI mute state and reads the first byte from the returned object. However, the returned ACPI object is owned by the caller and is never freed after use, so each successful query leaks the _DSM result object. The code also assumes that the returned object is a buffer with at least one byte. A malformed firmware response can return a different object type or an empty buffer, and the direct ret->buffer.pointer dereference can then access an invalid pointer. Use the typed _DSM helper, validate that the returned buffer contains at least one byte, and free the ACPI object after reading it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2025-40098", "url": "https://ubuntu.com/security/CVE-2025-40098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: hda: cs35l41: Fix NULL pointer dereference in cs35l41_get_acpi_mute_state() Return value of a function acpi_evaluate_dsm() is dereferenced without checking for NULL, but it is usually checked for this function. acpi_evaluate_dsm() may return NULL, when acpi_evaluate_object() returns acpi_status other than ACPI_SUCCESS, so add a check to prevent the crach. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2025-10-30 10:15:00 UTC" }, { "cve": "CVE-2026-68442", "url": "https://ubuntu.com/security/CVE-2026-68442", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: don't propagate EXTENT_FLAG_LOGGING to split extent maps When btrfs_drop_extent_map_range() splits an extent map, the new split maps inherit the original map's flags through a local 'flags' variable. Commit f86f7a75e2fb (\"btrfs: use the flags of an extent map to identify the compression type\") changed the EXTENT_FLAG_LOGGING clearing to operate on em->flags instead of that local 'flags' copy, so a split of an extent map that is currently being logged wrongly inherits EXTENT_FLAG_LOGGING. The flag is then never cleared on the split, and when it is freed while still on the inode's modified_extents list (for example by the extent map shrinker) it trips the WARN_ON(!list_empty(&em->list)) in btrfs_free_extent_map() and leads to a use-after-free. Clear EXTENT_FLAG_LOGGING from the local 'flags' copy used for the splits and only clear EXTENT_FLAG_PINNED from em->flags, restoring the behaviour prior to f86f7a75e2fb.", "cve_priority": "high", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68443", "url": "https://ubuntu.com/security/CVE-2026-68443", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (gigabyte_waterforce) Stop device IO before calling hid_hw_stop Calling hid_hw_stop() does not stop the device IO. This results in a race condition between hid_input_report() and the point immediately following the execution of hid_device_io_start() within the driver probe function. If the probe operation fails after \"io start\" has been initiated, this race condition will result in a UAF vulnerability. Fix the problem by calling hid_device_io_stop() before calling hid_hw_stop().", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68372", "url": "https://ubuntu.com/security/CVE-2026-68372", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: core: port: Deattach Type-C connector on component unbind connector_unbind() is the mirror of connector_bind(), but it is missing the symmetric call to typec_deattach() that connector_bind() makes via: if (port_dev->child) typec_attach(port_dev->connector, &port_dev->child->dev); When a Thunderbolt dock is unplugged, two teardown paths race: 1. The component framework calls connector_unbind() first, which sets port_dev->connector = NULL without calling typec_deattach(). This leaves port->usb2_dev/port->usb3_dev in struct typec_port pointing at the USB device that is about to be freed. 2. usb_disconnect() then calls typec_deattach(port_dev->connector, ...), but port_dev->connector is already NULL, so the call is a no-op and port->usb2_dev is never cleared. 3. Concurrently, UCSI detects a PD partner-disconnect event and calls typec_unregister_partner(), which reads port->usb2_dev (now a dangling pointer to freed memory) and passes it to typec_partner_unlink_device() -> sysfs_remove_link() -> dev_name() on the freed device, corrupting the typec/UCSI partner state. This corruption leaves the Thunderbolt tunnel in an inconsistent state on the next dock hot-plug. On affected hardware the dock's I225/igc NIC fails to enumerate: AER fires a slot reset while the igc driver is still initialising (\"PCIe link lost\"), and the subsequent igc_reset attempt hits igc_rd32 on an already-detached device: igc 0000:2e:00.0 eth0: PCIe link lost, device now detached igc: Failed to read reg 0x0! WARNING: CPU: 9 PID: 129 at drivers/net/ethernet/intel/igc/igc_main.c:7005 igc_rd32+0xa4/0xc0 [igc] Call Trace: igc_disable_pcie_master+0x16/0xa0 [igc] igc_reset_hw_base+0x14/0x170 [igc] igc_reset+0x63/0x110 [igc] igc_io_slot_reset+0x9e/0xd0 [igc] report_slot_reset+0x5d/0xc0 pcie_do_recovery+0x209/0x400 aer_isr_one_error_type+0x235/0x430 aer_isr+0x4e/0x80 irq_thread+0xf4/0x1f0 4. UCSI later handles the PD partner-disconnect and calls typec_unregister_partner(), which still sees the stale port->usb2_dev and tries to remove its sysfs link a second time: kernfs: can not remove 'typec', no directory WARNING: CPU: 6 PID: 55 at fs/kernfs/dir.c:1706 kernfs_remove_by_name_ns+0xe9/0xf0 Workqueue: events ucsi_handle_connector_change [typec_ucsi] Call Trace: sysfs_remove_link+0x19/0x50 typec_unregister_partner+0x6e/0x120 [typec] ucsi_unregister_partner+0x107/0x150 [typec_ucsi] ucsi_handle_connector_change+0x3ec/0x490 [typec_ucsi] process_one_work+0x18e/0x3e0 worker_thread+0x2e3/0x420 kthread+0x10a/0x230 ret_from_fork+0x121/0x140 ret_from_fork_asm+0x1a/0x30 With worse timing the same stale pointer is dereferenced after the backing memory is freed, turning the warning into a use-after-free. Fix the asymmetry: call typec_deattach() before clearing port_dev->connector, matching what connector_bind() does on the bind side. typec_partner_deattach() is already protected by port->partner_link_lock, so it serialises safely with the concurrent typec_unregister_partner() path.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68396", "url": "https://ubuntu.com/security/CVE-2026-68396", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: core: wake eh reliably when using scsi_schedule_eh Drivers which use the scsi_schedule_eh function to run the error handler currently risk the error handler thread never waking once all commands are timed out or inactive. There is no enforced memory order between setting the host into error recovery state and counting busy commands. This can result in a race with scsi_dec_host_busy where neither CPU sees both conditions of all commands inactive and the host error state to request waking the error handler. To fix this, run the scsi_schedule_eh's scsi_eh_wakeup from a new work item which will use rcu to ensure scsi_schedule_eh's call to scsi_host_busy will occur after the error state is globally visible and will be seen by any current scsi_dec_host_busy callers.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68408", "url": "https://ubuntu.com/security/CVE-2026-68408", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: convert pmsr_free_wk to wiphy_work to fix deadlock When a netlink socket that owns a PMSR session is closed, cfg80211_release_pmsr() clears the request's nl_portid and queues pmsr_free_wk to call cfg80211_pmsr_process_abort() asynchronously. If the interface tears down concurrently, cfg80211_pmsr_wdev_down() is called under wiphy_lock and calls cancel_work_sync(&pmsr_free_wk) to wait for any running work. The work function acquires wiphy_lock via guard(wiphy) before calling process_abort. This is a deadlock: wdev_down holds wiphy_lock and blocks inside cancel_work_sync(); pmsr_free_wk blocks trying to acquire that same wiphy_lock. Neither thread can proceed. The same deadlock is reachable from cfg80211_leave_locked(), which calls cfg80211_pmsr_wdev_down() for all interface types under wiphy_lock. Fix this by converting pmsr_free_wk from a plain work_struct to a wiphy_work. The wiphy_work dispatcher holds wiphy_lock when running work items, so the explicit guard(wiphy) in the work function is no longer needed. wiphy_work_cancel() can be called safely while holding wiphy_lock - since wiphy_lock prevents the work from running concurrently, wiphy_work_cancel() never blocks, eliminating the deadlock. Remove the cancel_work_sync() for pmsr_free_wk from the NETDEV_GOING_DOWN handler. cfg80211_leave(), called unconditionally just before it, already cancels any pending work under wiphy_lock via wiphy_work_cancel() inside cfg80211_pmsr_wdev_down().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64570", "url": "https://ubuntu.com/security/CVE-2026-64570", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: fix fils_discovery double free on alloc failure ieee80211_set_fils_discovery() calls kfree_rcu() on the old template before allocating the replacement. If the kzalloc() then fails, it returns -ENOMEM while link->u.ap.fils_discovery still points at the object already queued for freeing. A later update or AP teardown (ieee80211_stop_ap()) re-queues that same rcu_head; the second free is caught by KASAN when the RCU sheaf is processed in softirq: BUG: KASAN: double-free in rcu_free_sheaf (mm/slub.c:5850) Free of addr ffff88800c065280 by task swapper/0/0 ... __rcu_free_sheaf_prepare (mm/slub.c:2634 mm/slub.c:2940) rcu_free_sheaf (mm/slub.c:5850) rcu_core (kernel/rcu/tree.c:2617 kernel/rcu/tree.c:2869) handle_softirqs (kernel/softirq.c:622) The buggy address belongs to the cache kmalloc-96 of size 96 Queue the old object for kfree_rcu() only after the new one is published, matching ieee80211_set_probe_resp() and ieee80211_set_s1g_short_beacon().", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-64568", "url": "https://ubuntu.com/security/CVE-2026-64568", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: fix unsol_bcast_probe_resp double free on alloc failure ieee80211_set_unsol_bcast_probe_resp() calls kfree_rcu() on the old template before allocating the replacement. If the kzalloc() then fails, it returns -ENOMEM while link->u.ap.unsol_bcast_probe_resp still points at the object already queued for freeing. A later update or AP teardown re-queues that same rcu_head; the second free is caught by KASAN when the RCU sheaf is processed in softirq: BUG: KASAN: double-free in rcu_free_sheaf (mm/slub.c:5850) Free of addr ffff88800d06f300 by task exploit/145 ... __rcu_free_sheaf_prepare (mm/slub.c:2634 mm/slub.c:2940) rcu_free_sheaf (mm/slub.c:5850) rcu_core (kernel/rcu/tree.c:2617 kernel/rcu/tree.c:2869) handle_softirqs (kernel/softirq.c:622) The buggy address belongs to the cache kmalloc-128 of size 128 Queue the old object for kfree_rcu() only after the new one is published, matching ieee80211_set_probe_resp() and ieee80211_set_s1g_short_beacon().", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-72175", "url": "https://ubuntu.com/security/CVE-2026-72175", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/proc/task_mmu: fix make_uffd_wp_huge_pte() prot-update race Patch series \"userfaultfd/pagemap: pre-existing fixes\". These are pre-existing bug fixes that were carried at the front of the userfaultfd RWP working-set-tracking series up to v5 [1]. Per review feedback that fixes should not sit in the middle of a feature series, they are split out and sent on their own; the RWP series is reposted rebased on top of this. All six were flagged by the Sashiko AI review of the RWP series and carry independent of RWP, apply to mm-new directly, and carry Cc: stable@. 1: fs/proc/task_mmu: a missing huge_ptep_modify_prot_start() in make_uffd_wp_huge_pte() can lose hardware Dirty/Accessed updates when PAGEMAP_SCAN write-protects a hugetlb PTE. 2: fs/proc/task_mmu: pagemap_scan_hugetlb_entry() compares the range against HPAGE_SIZE rather than the hstate page size, so it never write-protects gigantic hugetlb pages. 3: fs/proc/task_mmu: PAGEMAP_SCAN with PM_SCAN_WP_MATCHING over an unpopulated hugetlb range self-deadlocks -- pagemap_scan_pte_hole() calls uffd_wp_range() while walk_hugetlb_range() holds the hugetlb vma lock for read, and hugetlb_change_protection() then takes it for write. Install the marker inline instead. 4: mm/huge_memory: change_non_present_huge_pmd() drops pmd_swp_uffd_wp on a device-private PMD permission downgrade, silently losing the uffd-wp marker. 5: userfaultfd: must_wait() applies pte_write() to a locklessly read PTE without checking pte_present(), so swap/migration entries decode random offset bits and a thread can stay parked on a stale fault. 6: userfaultfd: __VMA_UFFD_FLAGS feeds VMA_UFFD_MINOR_BIT (41) to mk_vma_flags() unconditionally, an out-of-bounds write into the single-word vma_flags_t on 32-bit. Build the mask from config-gated per-mode masks so an unavailable bit is never materialised. This patch (of 6): make_uffd_wp_huge_pte() arms the UFFD_WP bit on a present HugeTLB PTE by calling huge_ptep_modify_prot_commit() with a ptent snapshot that was fetched without the corresponding huge_ptep_modify_prot_start(). The start helper is what atomically clears the entry so the kernel-owned snapshot stays consistent until the commit; without it, the hardware may set Dirty or Accessed in the live PTE between the original read and the commit, and huge_ptep_modify_prot_commit() (whose generic implementation just calls set_huge_pte_at()) then writes the stale snapshot back over the live hardware bits, losing the update. The non-hugetlb sibling make_uffd_wp_pte() does this correctly via ptep_modify_prot_start() / ptep_modify_prot_commit(). Mirror that pattern for the present-PTE branch. The migration case stays as-is -- migration entries are non-present, so there's no hardware update to race against.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-45901", "url": "https://ubuntu.com/security/CVE-2026-45901", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: revert commit_mutex usage in reset path It causes circular lock dependency between commit_mutex, nfnl_subsys_ipset and nlk_cb_mutex when nft reset, ipset list, and iptables-nft with '-m set' rule run at the same time. Previous patches made it safe to run individual reset handlers concurrently so commit_mutex is no longer required to prevent this.", "cve_priority": "medium", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-45897", "url": "https://ubuntu.com/security/CVE-2026-45897", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_counter: serialize reset with spinlock Add a global static spinlock to serialize counter fetch+reset operations, preventing concurrent dump-and-reset from underrunning values. The lock is taken before fetching the total so that two parallel resets cannot both read the same counter values and then both subtract them. A global lock is used for simplicity since resets are infrequent. If this becomes a bottleneck, it can be replaced with a per-net lock later.", "cve_priority": "low", "cve_public_date": "2026-05-27 14:17:00 UTC" }, { "cve": "CVE-2026-68093", "url": "https://ubuntu.com/security/CVE-2026-68093", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: SVM: Bump asid_generation on CPU online to avoid ASID collision after hotplug If a vCPU stays scheduled out (or blocked) while the last pCPU it ran on goes through a hotplug cycle (online->offline->online), and the vCPU then resumes execution on the same pCPU, then it is possible for it to run with an ASID that has now been assigned to a different vCPU, resulting in stale TLB translations being used. svm_enable_virtualization_cpu() resets asid_generation to 1 and sets next_asid to max_asid + 1 on every CPU online event, including hotplug cycles. Because next_asid starts beyond the pool boundary, the first call to new_asid() after an online event always wraps the pool, incrementing asid_generation to 2 and assigning ASIDs starting from min_asid. Consider two vCPUs from different VMs, vCPU-A pinned to CPU-X holding asid_generation=2 and ASID=N from before the hotplug event: 1. CPU-X goes offline and back online: asid_generation resets to 1, next_asid = max_asid + 1. 2. One or more vCPUs migrate to CPU-X and call new_asid(), wrapping the pool and consuming ASIDs starting from min_asid. Eventually vCPU-B from a different VM is assigned asid_generation=2, ASID=N — the same ASID that vCPU-A held before the hotplug. 3. vCPU-A enters pre_svm_run() on CPU-X: current_vmcb->cpu is unchanged so the migration branch is skipped. Its saved asid_generation=2 matches sd->asid_generation=2, so the generation check silently passes and vCPU-A continues running with ASID=N — the same ASID just freshly assigned to vCPU-B. Both vCPUs from different VMs now run on CPU-X with the same ASID, causing them to share NPT TLB entries and producing stale translations. The collision manifests as a KVM internal error (Suberror: 1, emulation failure). The NPT page fault reports a faulting GPA far outside the VM's physical memory range — a sign of stale TLB translations being used. KVM falls back to instruction emulation, which fails on FPU/XSave instructions (XRSTOR, STMXCSR) that the emulator does not implement. Fix this by incrementing asid_generation instead of resetting it to 1 in svm_enable_virtualization_cpu(). On module load, asid_generation starts at 0 (memset) and the increment produces 1, identical to the old behaviour. On subsequent hotplug cycles the generation advances beyond any value a vCPU previously observed on this CPU, so the generation check in pre_svm_run() reliably forces new_asid() on every vCPU after every hotplug cycle.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68164", "url": "https://ubuntu.com/security/CVE-2026-68164", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/damon/core: disallow overlapping input ranges for damon_set_regions() damon_set_regions() assumes the input ranges are sorted by the address and don't overlap each other. Hence the assumption was initially to be explicitly validated. But commit 97d482f4592f (\"mm/damon/sysfs: reuse damon_set_regions() for regions setting\") has mistakenly removed the validation. This can make DAMON behave in unexpected ways. At the best, the monitoring results snapshot will just look weird since there will be overlapping regions. DAMOS will also work weirdly, applying the same action multiple times for overlapping regions, and make DAMOS quota weird. More seriously, depending on the setup and regions updates sequence, negative size regions can be made. It will trigger WARN_ONCE() if the kernel is built with CONFIG_DAMON_DEBUG_SANITY=y. Depending on the monitoring results, the negative size region can further trigger division by zero in damon_merge_two_regions(). Note that some of the consequences including the WARN_ONCE() and the divide by zero depend on commits that were introduced after the root cause commit 97d482f4592f (\"mm/damon/sysfs: reuse damon_set_regions() for regions setting\"). Fix the problems by checking the assumption and returning an error if the input ranges don't meet the assumption. The issue was discovered [1] by Sashiko.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68165", "url": "https://ubuntu.com/security/CVE-2026-68165", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/damon/core: validate ranges in damon_set_regions() DAMON core logic assumes zero length regions don't exist. However, a few DAMON API callers including DAMON_SYSFS, DAMON_RECLAIM and DAMON_LRU_SORT allow users to set empty monitoring target regions. This could result in WARN_ONCE() on CONFIG_DAMON_DEBUG_SANITY enabled kernel, and divide-by-zero from damon_merge_two_regions(). For example, the WANR_ONCE() can be triggered like below. # grep DAMON_DEBUG_SANITY /boot/config-$(uname -r) # CONFIG_DAMON_DEBUG_SANITY=y # damo start # cd /sys/kernel/mm/damon/admin/kdamonds/0 # echo 0 > contexts/0/targets/0/regions/0/start # echo 0 > contexts/0/targets/0/regions/0/end # echo commit > state # dmesg [....] [ 73.705780] ------------[ cut here ]------------ [ 73.707552] start 0 >= end 0 [ 73.708452] WARNING: mm/damon/core.c:359 at damon_new_region+0x6e/0x80, CPU#1: kdamond.0/758 [...] All DAMON API callers eventually use damon_set_regions() to setup the regions. Add the validation logic in the function.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-72015", "url": "https://ubuntu.com/security/CVE-2026-72015", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/resctrl: Fix double-add of pseudo-locked region's RMID to free list A pseudo-locked group's RMID is freed when it is created. On unmount rmdir_all_sub() unconditionally frees all RMID of all groups, resulting in a double-free of the pseudo-locked group's RMID. The consequence of this is that the original free results in the pseudo-locked group's RMID being added to the rmid_free_lru linked list and the second free then attempts to add the same RMID entry to the rmid_free_lru again. Do not double-free a pseudo-locked group's RMID.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72017", "url": "https://ubuntu.com/security/CVE-2026-72017", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: macb: drop in-flight Tx SKBs on close The MACB driver has since forever leaked the outgoing SKBs that have not yet been marked as completed. They live in queue->tx_skb which gets freed without remorse nor checking. macb_free_consistent() gets called in a few codepaths, but only close will trigger the added expressions. In macb_open() and macb_alloc_consistent() failure cases, queues' tx_skb just got allocated and are empty.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72030", "url": "https://ubuntu.com/security/CVE-2026-72030", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ata: libata-core: Reject an invalid concurrent positioning ranges count ata_dev_config_cpr() takes the number of range descriptors from buf[0] of the concurrent positioning ranges log (up to 255), which the device reports independently of the log size in the GPL directory. The count is then walked at a fixed 32-byte stride in two places with no bound: the log read here, and the INQUIRY VPD page B9h emitter, which writes one descriptor per range into the fixed 2048-byte ata_scsi_rbuf. A device reporting a count larger than its own log overflows the read buffer (up to 7704 bytes past a 512-byte slab), and a count above 62 overflows the response buffer on the emit side. Bound the count once, on probe, against both the log the device returned and the number of descriptors the VPD B9h response buffer can hold (ATA_DEV_MAX_CPR, derived from the rbuf size). Reject an out-of-range count with a warning; this keeps the emitter in bounds with no separate change there.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72023", "url": "https://ubuntu.com/security/CVE-2026-72023", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: octeontx2-pf: fix SQB pointer leak on init failure otx2_init_hw_resources() initializes SQ aura and pool resources before several later setup steps. On failure, err_free_sq_ptrs only frees SQB pages, leaving the per-SQ sqb_ptrs arrays behind. Use otx2_free_sq_res() for the SQ unwind path and let it free sqb_ptrs even when sq->sqe has not been allocated yet. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in v7.1.1. An x86_64 allyesconfig build showed no new warnings. As we do not have an OcteonTX2 PF device and the corresponding AF mailbox setup to test with, no runtime testing was able to be performed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72040", "url": "https://ubuntu.com/security/CVE-2026-72040", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipmi: fix refcount leak in i_ipmi_request() When a caller provides a `supplied_recv` message to i_ipmi_request(), the function increments the user's `nr_msgs` reference count. If an error occurs later, the out_err cleanup path only frees the recv_msg if the function allocated it itself (i.e., !supplied_recv). In the supplied_recv case the cleanup is skipped, leaving the reference count elevated. The caller ipmi_request_supply_msgs() does not release the supplied_recv on error, so the reference is permanently leaked. Fix this by explicitly reverting the reference count operations when a supplied recv_msg with a valid user pointer is present in the error path: decrement nr_msgs and drop the user's kref.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72045", "url": "https://ubuntu.com/security/CVE-2026-72045", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: octeontx2-af: cn10k: restrict VF LMTLINE sharing to its own PF rvu_mbox_handler_lmtst_tbl_setup() uses req->base_pcifunc as a direct index into the LMT map table to read another function's LMTLINE physical base address and copy it into the caller's own LMT map table entry. The mailbox dispatcher authenticates req->hdr.pcifunc from the IRQ source, but req->base_pcifunc is a separate payload field and is not sanitized. Reject the request with -EPERM when a VF caller's base_pcifunc is not a valid function under its own PF. is_pf_func_valid() bounds the FUNC field to the PF's configured VF count, keeping the computed index inside the caller's own slot block.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72062", "url": "https://ubuntu.com/security/CVE-2026-72062", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpio: mt7621: avoid corruption of shared interrupt trigger state The bank-shared fields like 'rising' and 'falling' are modified using non-atomic read-modify-write operations. Since every gpio chip instance represents an entire bank of 32 pins, if 'mediatek_gpio_irq_type()' is called concurrently for different IRQs on the same bank a possible overwrite of each other's configuration is possible. Thus, protect this state with 'gpio_generic_lock_irqsave' lock in the same way it is handled in irp_chip 'mediatek_gpio_irq_mask()' and 'mediatek_gpio_irq_unmask()' callbacks.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72051", "url": "https://ubuntu.com/security/CVE-2026-72051", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ip6_tunnel: require CAP_NET_ADMIN in the device netns for changelink ip6_tnl_changelink() operates on at most two netns, dev_net(dev) and the tunnel link netns t->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in t->net can rewrite a tunnel that lives in t->net. Gate ip6_tnl_changelink() on rtnl_dev_link_net_capable() at its top, before any attribute is parsed.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72065", "url": "https://ubuntu.com/security/CVE-2026-72065", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: mana: Validate the packet length reported by the NIC Validate the packet length reported in the RX CQE before passing it to skb processing. The CQE is supplied by the NIC device and should not be blindly trusted.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72069", "url": "https://ubuntu.com/security/CVE-2026-72069", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: locking/rt: Fix the incorrect RCU protection in rt_spin_unlock() rt_spin_unlock() releases the RCU protection before unlocking the lock. That opens the door for the following UAF scenario: T1\t\t\t\t\tT2 spin_lock(&p->lock);\t\trcu_read_lock(); invalidate(p);\t\t\tp = rcu_dereference(ptr); rcu_assign_pointer(ptr, NULL);\tif (!p) return; spin_unlock(&p->lock);\t\tspin_lock(&p->lock) \t\t\t\t lock(&lock->lock); \t\t\t\t rcu_read_lock(); kfree_rcu(p);\t\t\trcu_read_unlock(); \t\t\t\t.... \t\t\t\tspin_unlock(&p->lock) \t\t\t\t rcu_read_unlock(); // Ends grace period rcu_do_batch() kfree(p); \t\t\t UAF ->\t rt_mutex_cmpxchg_release(&lock->lock...) Regular spinlocks keep preemption disabled accross the unlock operation, which provides full RCU protection, but the RT substitution fails to resemble that. Same applies for the rwlock substitution. Move the rcu_read_unlock() invocation past the unlock operations to match the non-RT semantics. This makes it asymmetric vs. rt_xxx_lock(), but that's harmless as the caller needs to hold RCU read lock across the lock operation. The migrate_enable() call stays before the unlock operation because there is no per CPU operation in the unlock path which would require migration to be kept disabled.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72070", "url": "https://ubuntu.com/security/CVE-2026-72070", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: libertas_tf: fix use-after-free in lbtf_free_adapter() lbtf_free_adapter() calls timer_delete(&priv->command_timer), which does not wait for a running command_timer_fn() callback. lbtf_free_adapter() runs on the teardown path right before ieee80211_free_hw() frees priv, both in lbtf_remove_card() and in the probe error path. command_timer is armed by mod_timer() in lbtf_cmd() whenever a firmware command is sent. command_timer_fn() dereferences priv. If a command times out as the device is removed, command_timer_fn() runs concurrently with teardown and dereferences priv after it has been freed. This is the same use-after-free that commit 03cc8f90d053 (\"wifi: libertas: fix use-after-free in lbs_free_adapter()\") fixed in the sibling libertas driver. The libertas_tf variant has the identical pattern and was left unchanged. Use timer_delete_sync() so any in-flight callback completes before priv is freed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72142", "url": "https://ubuntu.com/security/CVE-2026-72142", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: imx: fix locked bus on SMBus block-read of 0 (atomic) SMBus 3.1 6.5.7 allows a Block Read byte count of 0, but the atomic (polling) path rejects it as -EPROTO. Worse, it returns without a NACK+STOP: the next receive cycle has already started, so the target keeps holding SDA and the bus stays stuck until a power cycle for this i2c controller. Reading I2DR to obtain the count likewise arms the next byte on the count > I2C_SMBUS_BLOCK_MAX path, which also returned -EPROTO directly and left the bus held. Handle both: NACK the in-flight dummy byte (TXAK) and extend msgs->len so the existing last-byte handling emits STOP; the dummy byte is discarded. A count of 0 is a valid empty block read; a count above I2C_SMBUS_BLOCK_MAX is still reported as -EPROTO, but only after the bus has been released. The interrupt-driven path has the same flaw from a later commit and is fixed separately, as it carries a different Fixes: tag and stable range.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72147", "url": "https://ubuntu.com/security/CVE-2026-72147", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: dw-edma-pcie: Reject devices without driver data dw_edma_pcie_probe() treats the PCI device ID driver_data as the template for the controller layout and copies it unconditionally. A device bound dynamically via sysfs can match the driver without that data, which leads to a NULL pointer dereference. Reject such matches before enabling the device.", "cve_priority": "low", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72254", "url": "https://ubuntu.com/security/CVE-2026-72254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_fib: reject fib expression on the netdev egress hook A fib expression in a netdev egress base chain dereferences nft_in(pkt), NULL on the transmit path, causing a NULL pointer dereference at eval. nft_fib_validate() masks the hook with NF_INET_* values, but netdev hook numbers are a separate enum that aliases them (NF_NETDEV_EGRESS == NF_INET_LOCAL_IN), so an egress chain passes validation and then faults. Add nft_fib_netdev_validate() that limits each result/flag to the netdev hook where the device it reads exists: the input-device cases (OIF, OIFNAME, ADDRTYPE with F_IIF) to ingress, the output-device case (ADDRTYPE with F_OIF) to egress, ADDRTYPE with no device flag to both. Also restrict nft_fib_validate() to NFPROTO_IPV4/IPV6/INET so its NF_INET_* masks are not applied to another family's hooks.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72253", "url": "https://ubuntu.com/security/CVE-2026-72253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack_sip: validate skb_dst() before accessing it tc ingress and openvswitch do not guarantee routing information to be available. These subsystems use the conntrack helper infrastructure, and the SIP helper relies on the skb_dst() to be present if sip_external_media is set to 1 (which is disabled by default as a module parameter). This effectively disables the sip_external_media toggle for these subsystems without resulting in a crash.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72260", "url": "https://ubuntu.com/security/CVE-2026-72260", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: mediatek: mt8192: Check runtime resume during probe The MT8192 AFE probe enables runtime PM temporarily while reinitializing the regmap cache from hardware, but it uses pm_runtime_get_sync() without checking the return value. If runtime resume fails, probe keeps going without the device necessarily being accessible, and pm_runtime_get_sync() may leave the PM usage count incremented. The regmap_reinit_cache() failure path also returns before dropping the temporary PM reference and before clearing pm_runtime_bypass_reg_ctl. Use pm_runtime_resume_and_get() so resume failures do not leak a usage count, and clear the temporary bypass flag after dropping the probe PM reference on all regmap_reinit_cache() outcomes.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72305", "url": "https://ubuntu.com/security/CVE-2026-72305", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: VDUSE: avoid leaking information to userspace The bounceing is not necessarily page aligned, so current VDUSE can leak kernel information through mapping bounce pages to userspace. Allocate bounce pages with __GFP_ZERO to avoid leaking information to userspace.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-72299", "url": "https://ubuntu.com/security/CVE-2026-72299", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: restrict socket queue dumps in enqueue tracepoints tipc_sk_enqueue() runs with sk->sk_lock.slock held while the socket is owned by user context. The spinlock protects the backlog queue in this path, but it does not serialize against the socket owner consuming or purging sk_receive_queue. KASAN reported: CPU: 14 UID: 0 PID: 1050 Comm: tipc3 Not tainted 7.1.0-rc6+ #126 PREEMPT(lazy) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Call Trace: dump_stack_lvl+0x76/0xa0 lib/dump_stack.c:123 print_report+0xce/0x5b0 mm/kasan/report.c:482 kasan_report+0xc6/0x100 mm/kasan/report.c:597 __asan_report_load4_noabort+0x14/0x30 mm/kasan/report_generic.c:380 tipc_skb_dump+0x1327/0x16f0 net/tipc/trace.c:73 tipc_list_dump+0x208/0x2e0 net/tipc/trace.c:187 tipc_sk_dump+0xaf6/0xd60 net/tipc/socket.c:3996 trace_event_raw_event_tipc_sk_class+0x312/0x5a0 net/tipc/trace.h:188 tipc_sk_rcv+0xb1d/0x1d50 net/tipc/socket.c:2497 tipc_node_xmit+0x1c3/0x1440 net/tipc/node.c:1689 __tipc_sendmsg+0x97a/0x1440 net/tipc/socket.c:1512 tipc_sendmsg+0x52/0x80 net/tipc/socket.c:1400 sock_sendmsg+0x2f6/0x3e0 net/socket.c:825 splice_to_socket+0x7f9/0x1010 fs/splice.c:884 do_splice+0xe21/0x2330 fs/splice.c:936 __do_splice+0x153/0x260 fs/splice.c:1431 __x64_sys_splice+0x150/0x230 fs/splice.c:1616 x64_sys_call+0xeb5/0x2790 arch/x86/entry/syscall_64.c:41 do_syscall_64+0xf3/0x620 arch/x86/entry/syscall_64.c:63 entry_SYSCALL_64_after_hwframe+0x76/0x7e arch/x86/entry/entry_64.S:130 RIP: 0033:0x71624e8aafe2 Code: 08 0f 85 71 3a ff ff 49 89 fb 48 89 f0 48 89 d7 48 89 ce 4c 89 c2 4d 89 ca 4c 8b 44 24 08 4c 8b 4c 24 10 4c 89 5c 24 08 0f 05 66 2e 0f 1f 84 00 00 00 00 00 66 2e 0f 1f 84 00 00 00 00 00 66 RSP: 002b:0000716157ffed68 EFLAGS: 00000246 ORIG_RAX: 0000000000000113 RAX: ffffffffffffffda RBX: 0000716157fff6c0 RCX: 000071624e8aafe2 RDX: 000000000000005f RSI: 0000000000000000 RDI: 0000000000000066 RBP: 0000716157ffed90 R08: 0000000000008000 R09: 0000000000000001 R10: 0000000000000000 R11: 0000000000000246 R12: ffffffffffffff00 R13: 0000000000000021 R14: 0000000000000000 R15: 00007fff89799c40 The TIPC_DUMP_ALL tracepoints in tipc_sk_enqueue() also dump sk_receive_queue and can therefore dereference skbs that the socket owner has already dequeued or freed. Restrict these dumps to TIPC_DUMP_SK_BKLGQ, which matches the queue protected by the held spinlock. Keep the change limited to the enqueue path, where the unsafe queue dump is reachable while the socket is owned by user context.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-74436", "url": "https://ubuntu.com/security/CVE-2026-74436", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: serialize kernel accept preallocation with socket teardown rxrpc_kernel_charge_accept() reads rx->backlog without any socket/backlog synchronization and passes that raw pointer into rxrpc_service_prealloc_one(). A concurrent rxrpc_discard_prealloc() sets rx->backlog = NULL and frees the backlog rings, so a kernel preallocation worker can keep using a freed struct rxrpc_backlog while updating *_backlog_head/tail and array slots. Serialize the state check and backlog lookup with the socket lock, and reject kernel preallocation once teardown has disabled listening or discarded the service backlog.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:22:00 UTC" }, { "cve": "CVE-2026-64205", "url": "https://ubuntu.com/security/CVE-2026-64205", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: i801: fix hardware state machine corruption in error path A severe livelock and subsequent Hung Task panic were observed in the i2c-i801 driver during concurrent Fuzzing. The crash is caused by an unconditional hardware register cleanup in the error handling path of i801_access(). When i801_check_pre() fails (e.g., returning -EBUSY because the SMBus controller is actively used by BIOS/ACPI), the kernel does not actually acquire the hardware ownership. However, the code jumps to the 'out' label and executes: iowrite8(SMBHSTSTS_INUSE_STS | STATUS_FLAGS, SMBHSTSTS(priv)); This forcefully clears the INUSE_STS lock and resets the hardware status flags without owning the controller. Doing so interrupts ongoing BIOS/ACPI transactions and totally corrupts the SMBus hardware state machine. Consequently, all subsequent i801_access() calls fail at the pre-check stage, triggering an endless stream of \"SMBus is busy, can't use it!\" error logs. Over a slow serial console, this printk flood monopolizes the CPU (Console Livelock), starving other processes trying to acquire the mmap_lock down_read semaphore, ultimately triggering the hung task watchdog. Fix this by moving the 'out' label below the hardware register cleanup. If i801_check_pre() fails, we safely bypass the iowrite8() and only release the software locks (pm_runtime and mutex), strictly adhering to the rule of not releasing resources that were never acquired.", "cve_priority": "medium", "cve_public_date": "2026-07-20 17:18:00 UTC" }, { "cve": "CVE-2026-68096", "url": "https://ubuntu.com/security/CVE-2026-68096", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: audit: fix recursive locking deadlock in audit_dupe_exe() A deadlock occurs in the audit subsystem when duplicating executable-related rules. When a file is moved (e.g., via do_renameat2()), the VFS layer locks the parent directory (I_MUTEX_PARENT), which synchronously triggers an fsnotify_move event. If an existing executable audit rule matches the file being moved, the audit subsystem catches this event and calls audit_dupe_exe() to duplicate the watch and update the rule. Then, audit_alloc_mark() would call kern_path_parent() to resolve the path, leading to a blind attempt to acquire the exact same I_MUTEX_PARENT lock already held by the task, resulting in the following recursive locking deadlock: ============================================ WARNING: possible recursive locking detected 6.12.0-55.27.1.el10_0.x86_64+debug #1 Not tainted -------------------------------------------- mv/5099 is trying to acquire lock: ffff888132845358 (&inode->i_sb->s_type->i_mutex_dir_key/1){+.+.}-{3:3}, at: __kern_path_locked+0x10a/0x2f0 but task is already holding lock: ffff888132846b58 (&inode->i_sb->s_type->i_mutex_dir_key/1){+.+.}-{3:3}, at: lock_two_directories+0x13f/0x2b0 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&inode->i_sb->s_type->i_mutex_dir_key/1); lock(&inode->i_sb->s_type->i_mutex_dir_key/1); *** DEADLOCK *** May be due to missing lock nesting notation 6 locks held by mv/5099: #0: ffff888112a9c440 (sb_writers#13) at: do_renameat2+0x34c/0xbc0 #1: ffff888112a9c790 (&type->s_vfs_rename_key#3) at: do_renameat2+0x415/0xbc0 #2: ffff888132846b58 (&inode->i_sb->s_type->i_mutex_dir_key/1) at: lock_two_directories+0x13f/0x2b0 #3: ffff888132845358 (&inode->i_sb->s_type->i_mutex_dir_key/5) at: lock_two_directories+0x175/0x2b0 #4: ffffffffb3a1fb10 (&fsnotify_mark_srcu) at: fsnotify+0x454/0x28a0 #5: ffffffffaf886230 (audit_filter_mutex) at: audit_update_watch+0x36/0x11e0 stack backtrace: Call Trace: dump_stack_lvl+0x6f/0xb0 print_deadlock_bug.cold+0xbd/0xca validate_chain+0x83a/0xf00 __lock_acquire+0xcac/0x1d20 lock_acquire.part.0+0x11b/0x360 down_write_nested+0x9f/0x230 __kern_path_locked+0x10a/0x2f0 kern_path_locked+0x26/0x40 audit_alloc_mark+0xfb/0x4f0 audit_dupe_exe+0x6c/0xe0 audit_dupe_rule+0x6c2/0xc00 audit_update_watch+0x4cc/0x11e0 audit_watch_handle_event+0x12c/0x1b0 send_to_group+0x5d0/0x8b0 fsnotify+0x615/0x28a0 fsnotify_move+0x1d8/0x630 vfs_rename+0xdcd/0x1df0 do_renameat2+0x9d4/0xbc0 __x64_sys_renameat+0x192/0x260 do_syscall_64+0x92/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f0491fe8c4e Code: 0f 1f 40 00 48 8b 15 c1 e1 16 00 f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa 49 89 ca b8 08 01 00 00 0f 05 <48> 3d 00 f0 ff ff 77 0a c3 66 0f 1f 84 00 00 00 00 00 48 8b 15 89 RSP: 002b:00007ffc7210bf38 EFLAGS: 00000246 ORIG_RAX: 0000000000000108 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f0491fe8c4e RDX: 0000000000000003 RSI: 00007ffc7210e6c8 RDI: 00000000ffffff9c RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000001 R10: 00005575eb2dae2a R11: 0000000000000246 R12: 00005575eb2dae2a R13: 00007ffc7210e6c8 R14: 0000000000000003 R15: 00000000ffffff9c The aforementioned deadlock can be consistently reproduced by running the script below: audit-dupe-exe-deadlock.sh -------------------------- #!/bin/bash auditctl -D mkdir -p /tmp/foo touch /tmp/file auditctl -a always,exit -F exe=/tmp/file -F path=/tmp/file -S all -k dr mv /tmp/file /tmp/foo/file rm -Rf /tmp/foo This patch fixes the issue by introducing struct audit_watch_ctx to pass the fsnotify event context down to audit_alloc_mark(). By utilizing the already-resolved directory inode provided by the event, we bypass the kern_path_parent() path resol ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-64280", "url": "https://ubuntu.com/security/CVE-2026-64280", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fpga: dfl-afu: validate DMA mapping length in afu_dma_map_region() afu_ioctl_dma_map() accepts a 64-bit length from userspace via DFL_FPGA_PORT_DMA_MAP ioctl without an upper bound check. The value is passed to afu_dma_pin_pages() where npages is derived as length >> PAGE_SHIFT and passed to pin_user_pages_fast() which takes int nr_pages, causing implicit truncation if length is very large. Validate map.length at the ioctl entry point before calling afu_dma_map_region(), rejecting values whose page count exceeds INT_MAX.", "cve_priority": "medium", "cve_public_date": "2026-07-25 10:17:00 UTC" }, { "cve": "CVE-2026-68147", "url": "https://ubuntu.com/security/CVE-2026-68147", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fscrypt: Avoid dynamic allocation in fscrypt_get_devices() When a blk_crypto_key starts being used or is evicted, fs/crypto/ calls fscrypt_get_devices() to get the filesystem's list of block devices, then iterates over them and calls blk_crypto_config_supported(), blk_crypto_start_using_key(), or blk_crypto_evict_key() on each one. Currently, the block device pointers are placed in a dynamically allocated array. This dynamic allocation is problematic because: - It can fail, especially at the fscrypt_destroy_inline_crypt_key() call site when it's invoked for inode eviction under direct reclaim. - fscrypt_destroy_inline_crypt_key() doesn't handle the failure. It just zeroizes and frees the blk_crypto_key without calling blk_crypto_evict_key(). That causes a use-after-free. For now, let's fix this in the straightforward and easily-backportable way by switching to an on-stack array. Currently the fscrypt multi-device functionality is used only by f2fs, which has a hardcoded limit of 8 block devices. An on-stack array works fine for that. (Of course, this solution won't scale up to large number of block devices. For that we'd need a different solution, like moving the block device iteration into the filesystem. Or in the case of btrfs, which will only support blk-crypto-fallback, we should make it just call blk-crypto-fallback directly, so the block devices won't be needed.)", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68123", "url": "https://ubuntu.com/security/CVE-2026-68123", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: openvswitch: fix GSO userspace truncation underflow OVS_ACTION_ATTR_TRUNC currently stores a delta from the original skb length in OVS_CB(skb)->cutlen. When a later userspace action segments a GSO skb, queue_gso_packets() reuses that delta for each smaller segment. A segment can then reach queue_userspace_packet() with cutlen greater than skb->len, underflowing the length passed to skb_zerocopy(). Store the maximum preserved length instead and bound each consumer against the current skb length. Use U32_MAX as the no-truncation sentinel so the value remains valid if skb geometry changes before a consumer handles it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68097", "url": "https://ubuntu.com/security/CVE-2026-68097", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate ACE size against SID sub-authorities set_ntacl_dacl() validates sid.num_subauth before copying an ACE, but does not verify that the declared ACE size contains all sub-authorities described by that field. An undersized ACE can therefore be copied and later make the POSIX ACL deduplication walk inspect data beyond the copied ACE boundary. The existing initial bound check is also too small. It only ensures that the ACE size field is accessible before set_ntacl_dacl() reads sid.num_subauth farther into the input buffer. Require enough input for the fixed SID header before accessing num_subauth, reject ACEs smaller than that header, and skip ACEs whose declared size cannot contain the complete SID. This makes the validation consistent with the other ACE walk paths.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68098", "url": "https://ubuntu.com/security/CVE-2026-68098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: bound DACL dedup walk to copied ACEs set_ntacl_dacl() can stop copying ACEs before consuming the full input DACL when size accounting overflows. When that happens, num_aces reflects only the ACEs that were actually copied into the output DACL, but set_posix_acl_entries_dacl() still receives nt_num_aces and uses it to walk the existing ACE array during dedup. That makes the dedup walk scan past the copied ACE array and inspect buffer tail that does not contain valid ACEs. Split the two meanings currently carried by the NT ACE count. Pass the number of copied NT ACEs to bound the dedup walk, and preserve the original \"input DACL had NT ACEs\" state separately for the Everyone/default ACL fallback. This keeps the dedup walk aligned with the ACEs that are actually present in the rebuilt DACL.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68099", "url": "https://ubuntu.com/security/CVE-2026-68099", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: restore DACL size on check_add_overflow() to avoid malformed ACL check_add_overflow() unconditionally writes the truncated sum into *d even on overflow, per its contract in include/linux/overflow.h. The four check_add_overflow() guards in set_posix_acl_entries_dacl() and set_ntacl_dacl() break out of the ACE-building loops on overflow, but the truncated *size is then consumed downstream at the end of set_ntacl_dacl(): pndacl->size = cpu_to_le16(le16_to_cpu(pndacl->size) + size); This produces an on-wire NT ACL whose pndacl->size under-reports the bytes actually written by the preceding fill_ace_for_sid()/memcpy() calls, yielding a malformed ACL that can trigger out-of-bounds reads when re-parsed by clients or ksmbd itself. Restore *size to its pre-addition value on each overflow branch (via `*size -= ace_sz` / `size -= nt_ace_size`) so that after the break, *size once again holds the cumulative size of the successfully-written ACEs. The committed ACL is then truncated-but-self-consistent rather than malformed. The ksmbd DACL builders are the only check_add_overflow() sites found where an overflow path breaks out of a loop and the destination value is consumed afterward. The other nearby break-style cases either return -EINVAL on overflow (transport_ipc.c) or break without consuming the overflowed destination value afterward (buildid.c).", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68100", "url": "https://ubuntu.com/security/CVE-2026-68100", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate num_subauth when copying ACE in set_ntacl_dacl set_ntacl_dacl() copies each ACE from the attacker-controlled stored security descriptor verbatim into the response DACL without checking sid.num_subauth. The ACE bytes (including an unchecked num_subauth) originate from an authenticated SMB2_SET_INFO(SecInfo=DACL) that is stored raw via ksmbd_vfs_set_sd_xattr(); parse_dacl() rejects a bad ACE with `break` rather than an error, so parse_sec_desc() still returns success and the malformed SD reaches the xattr intact. On a subsequent SMB2_QUERY_INFO(SecInfo=DACL) for an inode carrying a POSIX access ACL, build_sec_desc() -> set_ntacl_dacl() -> set_posix_acl_entries_dacl() walks the copied ACEs and reads ntace->sid.sub_auth[ntace->sid.num_subauth - 1] with num_subauth taken straight from the stored SD. Since sub_auth[] is fixed at SID_MAX_SUB_AUTHORITIES (15), a crafted num_subauth (e.g. 255) drives an out-of-bounds heap read of ~1 KB with an offset fully controlled by an authenticated client. The sibling functions already gate this field: parse_dacl() -- num_subauth == 0 || > SID_MAX_SUB_AUTHORITIES parse_sid() -- num_subauth > SID_MAX_SUB_AUTHORITIES smb_copy_sid() -- min_t(u8, num_subauth, SID_MAX_SUB_AUTHORITIES) set_ntacl_dacl() is the lone inconsistent path that omits the check. Add the same num_subauth validation in set_ntacl_dacl() before copying the ACE, matching the gate already enforced by parse_dacl().", "cve_priority": "high", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68104", "url": "https://ubuntu.com/security/CVE-2026-68104", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: invoke pm_genpd_remove() before freeing genpd Call pm_genpd_remove() to unregister from global list prior to releasing acp_genpd memory, and clear the pointer after free. (cherry picked from commit cd8650d7a91ee8b768e202354672553faa5cc1f2)", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68106", "url": "https://ubuntu.com/security/CVE-2026-68106", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix division by zero with invalid uvd dimensions When width or height is less than 16, width_in_mb or height_in_mb becomes 0, leading to fs_in_mb being 0. This causes a division by zero when calculating num_dpb_buffer in H264 and H264 Perf decode paths. Add validation to reject frames with width < 16 or height < 16 before performing any calculations that depend on these values. V2: Format change - move up all vaiable definitions. V3: Use warn_once to avoid spam. (cherry picked from commit 3e41d26c70b0a459d041cc19482a226c4b7423cb)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68429", "url": "https://ubuntu.com/security/CVE-2026-68429", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/dp_mst: Handle torn-down topology gracefully in drm_dp_mst_topology_queue_probe() A hotplug or link-loss event can tear down the MST topology (setting mgr->mst_state = false and mgr->mst_primary = NULL) concurrently with a caller invoking drm_dp_mst_topology_queue_probe(). Since the check is already performed under mgr->lock, the condition is not a programming error but a valid race -- the topology was valid when the caller decided to call this function, but was torn down before the lock was acquired. Replace the drm_WARN_ON() with a graceful early return. This eliminates spurious kernel warnings and the resulting compositor crashes observed when connecting/disconnecting DP MST monitors, while keeping the correct behavior of doing nothing when MST is not active. A drm_dbg_mst() trace is added so the skipped probe remains observable under MST debug logging. The existing WARN_ON(mgr->mst_primary) in drm_dp_mst_topology_mgr_set_mst() already catches the case where the topology is initialized twice, so no diagnostic coverage is lost.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68107", "url": "https://ubuntu.com/security/CVE-2026-68107", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/vcn4: avoid rereading IB param length Reuse the parameter length returned by vcn_v4_0_enc_find_ib_param() instead of rereading it from the IB. This avoids a potential TOCTOU issue if the IB contents change between reads. (cherry picked from commit dbb02b4755f8c1f3773263f2d779872c1c0c073a)", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68108", "url": "https://ubuntu.com/security/CVE-2026-68108", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/vce: fix integer overflow in image size Fix a security vulnerability where malicious VCE command streams with oversized dimensions (e.g. 65536×65536) cause 32-bit integer overflow, wrapping the calculated buffer size to 0. This bypasses validation and allows GPU firmware to perform out-of-bound memory access. The fix uses 64-bit arithmetic to detect overflow and rejects invalid dimensions before they reach the hardware. V2: remove redundant check V3: modify max height value V4: remove size64 (cherry picked from commit cbe408dba581755ad1279a487ec786d8927d778d)", "cve_priority": "high", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68110", "url": "https://ubuntu.com/security/CVE-2026-68110", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma4.4.2: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit fa4f86a148271e325e95287630a3a15a9cd35fdc)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68111", "url": "https://ubuntu.com/security/CVE-2026-68111", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx9: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit b71604f8685b0eba07866f4e8dc30f93e1931054)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68112", "url": "https://ubuntu.com/security/CVE-2026-68112", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx9.4.3: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit 5676593d08998d7a6d9e2d51d6b54b3820e3755c)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68430", "url": "https://ubuntu.com/security/CVE-2026-68430", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx8: drop unecessary BUG_ON() There's no need to crash the kernel for this case. (cherry picked from commit 4d7c25208ca612b754f3bf39e9f16e725b828891)", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68246", "url": "https://ubuntu.com/security/CVE-2026-68246", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx11: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit daa62107452d2451787c4248ca38fa2d1a0cbefd)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68115", "url": "https://ubuntu.com/security/CVE-2026-68115", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx10: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit ac6f00beb658239bced4aaed9efbb04a35348d48)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68116", "url": "https://ubuntu.com/security/CVE-2026-68116", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: mdb: Fix source list corruption on a failed replace When replacing the source list of an MDB remote entry, all existing sources are first marked for deletion and vxlan_mdb_remote_srcs_add() is then called to add the new source list. Sources present in the new list have their deletion mark cleared, and any sources left marked afterwards are removed. If vxlan_mdb_remote_srcs_add() fails partway through, its error path deletes all entries on the remote's source list. That rollback is only correct for its other caller, vxlan_mdb_remote_add(), where the remote was just allocated and the list contains solely entries added during the call. On the replace path the list also holds pre-existing sources, so a failed replace tears them down together with their (S, G) forwarding entries instead of leaving the entry unchanged. This is reachable from an existing (*, G) remote. An EXCLUDE filter that loses sources starts forwarding traffic that should be blocked, while an INCLUDE filter that loses sources drops traffic that should be forwarded. Mark entries created during the current pass with a new VXLAN_SGRP_F_NEW flag. On failure, delete only those entries and clear the deletion mark on the pre-existing ones, so a failed replace leaves the source list untouched. Retain the flag until the whole operation succeeds and then clear it. Also stop vxlan_mdb_remote_src_add() from deleting a pre-existing entry it only looked up when adding that entry's forwarding entry fails.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68117", "url": "https://ubuntu.com/security/CVE-2026-68117", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: clear sock->sk on the failed-insert path in tipc_sk_create() When tipc_sk_create() fails to insert the new socket (tipc_sk_insert() returns non-zero), its error path frees the sk with sk_free() but leaves sock->sk pointing at the freed object: \tif (tipc_sk_insert(tsk)) { \t\tsk_free(sk); \t\tpr_warn(\"Socket create failed; port number exhausted\\n\"); \t\treturn -EINVAL; \t} This is harmless for plain socket(): the syscall layer clears sock->ops before releasing, so tipc_release() is never called. It is not harmless on the accept() path. tipc_accept() creates the pre-allocated child socket with tipc_sk_create(net, new_sock, 0, kern); on failure it leaves new_sock->sk dangling and new_sock->ops non-NULL, and do_accept() then fput()s the new file, so __sock_release() -> tipc_release() runs lock_sock(new_sock->sk) on the freed sk -- a use-after-free write of the sk_lock spinlock. tipc_release() already guards this exact \"failed accept() releases a pre-allocated child\" case with \"if (sk == NULL) return 0;\", but the guard is bypassed because tipc_sk_create() left sock->sk non-NULL (dangling) rather than NULL. Clear sock->sk on the failed-insert path so the existing tipc_release() NULL check fires and the use-after-free is avoided. The tipc_sk_insert() failure is reached when the per-netns socket rhashtable hits its max_size (tsk_rht_params.max_size = 1048576, ~2M elements) -- i.e. once a netns holds ~2M TIPC sockets every insert returns -E2BIG. BUG: KASAN: slab-use-after-free in lock_sock_nested (net/core/sock.c:3839) Write of size 8 at addr ffff8880047cdc38 by task init/1 lock_sock_nested (net/core/sock.c:3839) tipc_release (net/tipc/socket.c:638) __sock_release (net/socket.c:710) sock_close (net/socket.c:1501) __fput (fs/file_table.c:512) Allocated by task 1: sk_alloc (net/core/sock.c:2308) tipc_sk_create (net/tipc/socket.c:487) tipc_accept (net/tipc/socket.c:2744) do_accept (net/socket.c:2034) Freed by task 1: __sk_destruct (net/core/sock.c:2391) tipc_sk_create (net/tipc/socket.c:504) tipc_accept (net/tipc/socket.c:2744) do_accept (net/socket.c:2034)", "cve_priority": "high", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68121", "url": "https://ubuntu.com/security/CVE-2026-68121", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pppoe: reload header pointer after dev_hard_header() pppoe_sendmsg() saves a pointer to the PPPoE header before calling dev_hard_header(). Device header callbacks are allowed to reallocate the skb head, invalidating pointers into it. This can happen when a send is blocked in copy_from_user() while the first non-Ethernet port is added to an empty team device. The team's delegated GRE header callback then expands the skb head. PPPoE subsequently writes six bytes through the stale pointer into the freed head. Reload the PPPoE header through the skb's network-header offset after device header creation. pskb_expand_head() updates that offset when it relocates the head.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68124", "url": "https://ubuntu.com/security/CVE-2026-68124", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mctp: serial: handle zero-length frames to prevent rx buffer overflow The MCTP serial receive state machine reads a frame length byte in mctp_serial_push_header() case 2 and validates it upper-bound-only: \tif (c > MCTP_SERIAL_FRAME_MTU) { \t\tdev->rxstate = STATE_ERR; \t} else { \t\tdev->rxlen = c; \t\tdev->rxpos = 0; \t\tdev->rxstate = STATE_DATA; \t\t... \t} A length of zero passes this check, so rxlen is set to 0 and the state machine advances to STATE_DATA. In mctp_serial_push() STATE_DATA, the incoming byte is stored and rxpos incremented before the terminator is \tdev->rxbuf[dev->rxpos] = c; \tdev->rxpos++; \tdev->rxstate = STATE_DATA; \tif (dev->rxpos == dev->rxlen) { \t\tdev->rxpos = 0; \t\tdev->rxstate = STATE_TRAILER; \t} With rxlen == 0 the \"rxpos == rxlen\" terminator can never fire (rxpos is already 1 on the first data byte), so subsequent bytes are written past the end of the fixed 74-byte rxbuf, which is the last member of the netdev private area. Every following data byte is an attacker-controlled 1-byte out-of-bounds heap write, and the overflow continues until a frame (0x7e) or escape byte resets the parser -- effectively unbounded. Reaching this requires CAP_NET_ADMIN to attach the N_MCTP line discipline and bring the resulting mctpserialN netdev up, after which the bytes arrive via the tty receive path. Route a zero-length frame straight to STATE_TRAILER instead of STATE_DATA. The trailer/framing bytes are still consumed, and the frame resolves to a zero-length skb that the MCTP core rejects; the parser never enters STATE_DATA with rxlen == 0, so the out-of-bounds write can no longer occur. KASAN, on a frame of 0x7e 0x01 0x00 followed by data bytes (before this change): UBSAN: array-index-out-of-bounds in drivers/net/mctp/mctp-serial.c:370 index 74 is out of range for type 'u8 [74]' BUG: KASAN: slab-out-of-bounds in mctp_serial_tty_receive_buf Write of size 1 at addr ... by task kworker/u16:0 mctp_serial_tty_receive_buf tty_ldisc_receive_buf flush_to_ldisc Allocated by task 152: alloc_netdev_mqs mctp_serial_open v2: route zero-length frames to STATE_TRAILER instead of STATE_ERR so the trailer/framing bytes are still consumed (Jeremy Kerr). Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68125", "url": "https://ubuntu.com/security/CVE-2026-68125", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mac802154: llsec: reject frames shorter than the authentication tag llsec_do_decrypt_auth() computes the associated-data length for the AEAD request as \tassoclen += datalen - authlen; where datalen is the number of bytes after the MAC header and authlen (4, 8 or 16) is the length of the authentication tag. Nothing verifies that the frame actually carries at least authlen payload bytes. A secured frame whose payload is shorter than the tag makes datalen - authlen negative; assoclen is then passed to aead_request_set_ad() as an unsigned value close to 4 GiB, so crypto_aead_decrypt() walks far off the end of the scatterlist that only spans the real frame. The frame is fully attacker-controlled and reaches this path from any IEEE 802.15.4 peer in radio range. Reject frames whose payload is shorter than the authentication tag before the subtraction. Dynamically reproduced on a KASAN kernel as a general-protection-fault in the AEAD scatterwalk, and the fix confirmed.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68126", "url": "https://ubuntu.com/security/CVE-2026-68126", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mac802154: hold an interface reference across the scan worker mac802154_scan_worker() captures the scanning sub-interface under RCU and then keeps dereferencing sdata->dev after rcu_read_unlock() and outside the rtnl -- in the failure traces, in mac802154_transmit_beacon_req() (skb->dev = sdata->dev), and in the end_scan cleanup. Nothing keeps that netdev alive across the worker iteration. A concurrent DEL_INTERFACE or PHY removal can unregister the interface once the worker drops the rtnl between its two drv_set_channel() sections. unregister_netdevice() frees the netdev asynchronously from netdev_run_todo() with the rtnl already dropped, so neither holding the rtnl nor the per-PHY IEEE802154_IS_SCANNING flag prevents a stale worker iteration from dereferencing the freed netdev -- a KASAN slab-use-after-free, reachable by racing TRIGGER_SCAN against DEL_INTERFACE (both CAP_NET_ADMIN). Pin the netdev with netdev_hold() while the RCU read lock is still held, and release it at every worker exit.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68127", "url": "https://ubuntu.com/security/CVE-2026-68127", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ila: reload IPv6 header after pskb_may_pull in checksum adjust ila_csum_adjust_transport() caches ip6h = ipv6_hdr(skb) before calling pskb_may_pull(). On a non-linear skb whose transport header sits in a page fragment, pskb_may_pull() can call __pskb_pull_tail() / pskb_expand_head() and free the old skb head, leaving ip6h dangling; the following get_csum_diff(ip6h, p) then reads freed memory. ila_update_ipv6_locator() uses ip6h (and the iaddr derived from it) again after the csum-adjust call and additionally writes the new locator through that pointer. Impact: a remote IPv6 packet routed through a configured ILA csum-adjust-transport route or receive-side mapping triggers a slab-use-after-free in ila_update_ipv6_locator() (KASAN). The route or mapping requires CAP_NET_ADMIN to configure, but trigger packets are unauthenticated once it exists. Reload ip6h after each pskb_may_pull() in ila_csum_adjust_transport() before the csum-diff read. In ila_update_ipv6_locator() only the ILA_CSUM_ADJUST_TRANSPORT case pulls the skb, so reload ip6h and iaddr in that case alone before the destination-address write; the neutral-map modes never pull and keep their cached pointers.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68130", "url": "https://ubuntu.com/security/CVE-2026-68130", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: defer destroy_previous_session() until after NTLM authentication In ntlm_authenticate(), destroy_previous_session() is called using a user pointer resolved from the client-supplied NTLM blob username field before the NTLMv2 response is validated. An authenticated attacker can set the NTLM blob username to match a victim account and set PreviousSessionId to the victim's session ID; destroy_previous_session() destroys the victim's session while ksmbd_decode_ntlmssp_auth_blob() subsequently rejects the request with -EPERM. Move destroy_previous_session() and the prev_id assignment to after ksmbd_decode_ntlmssp_auth_blob() returns success and use sess->user rather than the pre-authentication lookup result. This matches the ordering already used by krb5_authenticate(), where destroy_previous_session() is called only after ksmbd_krb5_authenticate() returns success.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68131", "url": "https://ubuntu.com/security/CVE-2026-68131", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rbd: Reset positive result codes to zero in object map update path In a reply message to an RBD request, a positive result code indicates a data payload, which is not allowed for writes. While rbd_osd_req_callback() already resets a positive result code for writes to zero, rbd_object_map_callback() does not. This allows a corrupted reply to an object map update to trigger the rbd_assert(*result < 0) in __rbd_obj_handle_request(). This happens, because rbd_object_map_callback() calls rbd_obj_handle_request() -> __rbd_obj_handle_request() and passes this positive result code. From __rbd_obj_handle_request(), rbd_obj_advance_write() is called, which leaves the positive result code unchanged and returns true. Therefore, the if(done && *result) branch is executed in __rbd_obj_handle_request() and the assertion triggers. This patch fixes the issue by adjusting the logic in the rbd_object_map_callback() path. A positive result code for an object map update is now reset to zero (similar to rbd_osd_req_callback()), and the message is subsequently handled the same way as if the result code was zero from the beginning. Additionally, a WARN_ON_ONCE() is added for this case.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68135", "url": "https://ubuntu.com/security/CVE-2026-68135", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hip04: fix RX buffer leak on build_skb failure When build_skb() fails in hip04_rx_poll(), the driver jumps to the refill path without releasing the current RX buffer and its DMA mapping. Installing a replacement buffer then overwrites the slot references and leaks both resources. Keep the current slot intact and return budget so NAPI retries the same buffer. Also free a newly allocated RX fragment when dma_map_single() fails. This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68137", "url": "https://ubuntu.com/security/CVE-2026-68137", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/x25: fix use-after-free in x25_kill_by_neigh() x25_kill_by_neigh() walks the global X.25 socket list looking for sockets attached to a terminating neighbour. x25_list_lock protects list membership while the lookup is in progress, but it does not pin a socket's lifetime after the lock is dropped. The function currently drops x25_list_lock before calling lock_sock(s). A concurrent close can run x25_release(), remove the same socket from x25_list, and drop the last socket reference in that window. The neighbour teardown path can then lock or inspect a freed struct sock/struct x25_sock. Take sock_hold(s) while x25_list_lock still proves that the list entry is live, then drop the temporary reference after the socket has been locked, rechecked, and released. Recheck x25_sk(s)->neighbour after lock_sock(), because another path may have disconnected the socket before this path acquired the socket lock. Restart the list walk after each disconnect because the list lock was dropped and the previous iterator state may no longer be valid. A QEMU/KASAN run against origin/master reproduced a slab-use-after-free in x25_kill_by_neigh().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68140", "url": "https://ubuntu.com/security/CVE-2026-68140", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/iucv: fix use-after-free of a severed iucv_path af_iucv queues not-yet-received message notifications on iucv->message_q, each holding a raw pointer to the connection's iucv_path. When the peer severs the connection, iucv_sever_path() frees that path with iucv_path_free() but leaves the notifications queued. A later recvmsg() drains message_q via iucv_process_message_q() and hands the stale path to message_receive() -- a use-after-free of the freed iucv_path. Drop the queued notifications when the path is severed; once the path is gone they can no longer be received. This also frees the notifications leaked when a socket is closed with messages still queued.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68141", "url": "https://ubuntu.com/security/CVE-2026-68141", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/af_iucv: fix NULL deref in afiucv_hs_callback_syn() afiucv_hs_callback_syn() allocates the child socket with GFP_ATOMIC. If the allocation fails, nsk is NULL. The connection-refused path is entered when the listen state check fails, the accept backlog is full, or nsk is NULL. The code unconditionally calls iucv_sock_kill(nsk) in that path. iucv_sock_kill() does not accept a NULL socket pointer and immediately dereferences sk via sock_flag(sk, SOCK_ZAPPED). When nsk is NULL, calling iucv_sock_kill(nsk) results in a NULL pointer dereference. Only call iucv_sock_kill() when a child socket was successfully allocated.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68142", "url": "https://ubuntu.com/security/CVE-2026-68142", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: geneve: require CAP_NET_ADMIN in the device netns for changelink A tunnel changelink() operates on at most two netns, dev_net(dev) and the sticky underlay netns geneve->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in geneve->net can rewrite a geneve device whose underlay lives in geneve->net. geneve_changelink() applies the new configuration against geneve->net: geneve_link_config() and the geneve_quiesce()/geneve_unquiesce() pair reopen the underlay sockets in that netns (geneve_sock_add() uses geneve->net), so the same reasoning as the tunnel changelink series applies here. Gate geneve_changelink() with rtnl_dev_link_net_capable(), at the top of the op before any attribute is parsed, matching ipgre_changelink() and the rest of the \"require CAP_NET_ADMIN in the device netns for changelink\" series. Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "low", "cve_public_date": "2026-08-10 13:19:00 UTC" }, { "cve": "CVE-2026-68143", "url": "https://ubuntu.com/security/CVE-2026-68143", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: slip: serialize receive against buffer reallocation sl_realloc_bufs() replaces rbuff and updates buffsize while holding sl->lock. slip_receive_buf() reads those fields and writes through rbuff without holding the lock. An MTU change can therefore race with receive processing. An MTU shrink can expose the new smaller rbuff with the old larger bound, causing an out-of-bounds write. A receive callback which already loaded the old rbuff can instead continue writing after that buffer has been freed. Serialize receive processing with sl_realloc_bufs() by holding sl->lock while consuming each receive batch.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68432", "url": "https://ubuntu.com/security/CVE-2026-68432", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vxlan: require CAP_NET_ADMIN in the device netns for changelink A tunnel changelink() operates on at most two netns, dev_net(dev) and the sticky underlay netns vxlan->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in vxlan->net can rewrite a vxlan device whose underlay lives in vxlan->net. vxlan_changelink() validates and applies the new configuration against vxlan->net (vxlan_config_validate(vxlan->net, ...)) and can reopen the underlay socket in that netns, so the same reasoning as the tunnel changelink series applies here. Gate vxlan_changelink() with rtnl_dev_link_net_capable(), at the top of the op before any attribute is parsed, matching ipgre_changelink() and the rest of the \"require CAP_NET_ADMIN in the device netns for changelink\" series. Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "low", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68144", "url": "https://ubuntu.com/security/CVE-2026-68144", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phonet: pep: fix use-after-free in pep_get_sb() pep_get_sb() doesn't consider that pskb_may_pull() might have relocated the skb data, and continue to access the older pointer, causing UAF. Reproduced under KASAN: BUG: KASAN: slab-use-after-free in pep_get_sb+0x234/0x3b0 Read of size 1 at addr ff11000105510f50 by task repro/157 pep_get_sb+0x234/0x3b0 pipe_handler_do_rcv+0x5f7/0xa10 pep_do_rcv+0x203/0x410 __sk_receive_skb+0x471/0x4a0 phonet_rcv+0x5b3/0x6c0 __netif_receive_skb+0xcc/0x1d0 Refetch the header with skb_header_pointer() after pskb_may_pull(), so the possibly stale pointer is no longer dereferenced. There are better ways to solve this, but, this is the less instrusive one.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68146", "url": "https://ubuntu.com/security/CVE-2026-68146", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ftrace: Add global mutex to serialize trace_parser access In ftrace, the trace_parser structure is allocated and initialized when a trace file is opened, and is subsequently used across write and release handlers to parse user input. The affected handler paths and their specific functions are: - Open paths: ftrace_regex_open(), ftrace_graph_open() - Write paths: ftrace_regex_write(), ftrace_graph_write() - Release paths: ftrace_regex_release(), ftrace_graph_release() If userspace opens a trace file descriptor and shares it across multiple threads, concurrent write calls will race on the parser's internal state, specifically the 'idx', 'cont', and 'buffer' fields, leading to corrupted input or undefined behavior. Fix this by adding a global mutex, parser_lock, to serialize all access to trace_parser across write and release paths, preventing concurrent corruption of parser state.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68148", "url": "https://ubuntu.com/security/CVE-2026-68148", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fscrypt: Add missing superblock check in find_or_insert_direct_key() The legacy 'fscrypt_direct_keys' table caches master keys that are used by v1 encryption policies that have FSCRYPT_POLICY_FLAG_DIRECT_KEY. It's just a global table for all filesystems (since the keys can be provided by the legacy process-subscribed keyrings mechanism, which makes it difficult to reuse super_block::s_master_keys). The entries in it ('struct fscrypt_direct_key') do contain a super_block pointer, though, for passing to fscrypt_destroy_inline_crypt_key() when the last inode that references the key is evicted. However, when finding the fscrypt_direct_key for an inode, we weren't actually comparing the super_block pointer. As a result, inodes with different super_blocks could point to the same fscrypt_direct_key. That could extend the lifetime of a fscrypt_direct_key beyond the super_block it points to, causing a use-after-free later. Fix this by creating distinct fscrypt_direct_key structs for distinct super_block structs. Note that this problem doesn't exist in the v2 policy equivalent (\"per-mode keys\"), since the data structures there are per super_block.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68149", "url": "https://ubuntu.com/security/CVE-2026-68149", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs: preserve ACL_DONT_CACHE state in forget_cached_acl() The ACL_DONT_CACHE state is meant to be a constant state for the inode for filesystems that want to opt out of posix acl caching. Commit facd61053cff1 (\"fuse: fixes after adapting to new posix acl api\") used this facility to opt out of posix acl caching for fuse inodes with fuse server that does not negotiate FUSE_POSIX_ACL (fc->posix_acl). The commit also takes care to gate the forget_all_cached_acls() call in fuse_set_acl() on fc->posix_acl because there is no need for it, but there are other placed in fuse code which call forget_all_cached_acls() unconditional to fc->posix_acl and those cause the loss of the ACL_DONT_CACHE state. This is not only a functional bug. Properly timed, a get_acl() from this fuse filesystem can return a stale cached value, as was observed in tests, because set_acl() does not invalidate the unintentional acl cache. We could fix this in fuse, but it actually makes no sense for the vfs helper forget_cached_acl() to invalidate the ACL_DONT_CACHE state, so let it not do that to fix fuse and future users of ACL_DONT_CACHE.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68151", "url": "https://ubuntu.com/security/CVE-2026-68151", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: binfmt_elf_fdpic: only honour the first PT_INTERP The program header scan handles PT_INTERP from a switch nested in the scan loop, so its break leaves the switch and not the loop. A binary carrying more than one PT_INTERP runs the case again and overwrites both interpreter_name and interpreter. The previous name allocation leaks and so does the previous interpreter reference, along with the write denial open_exec() took on it. The denial is never released, so the file stays unwritable for as long as the system runs. An unprivileged caller reaches this with a crafted binary and repeats it at will. binfmt_elf stops at the first PT_INTERP. Do the same here. The flaw dates back to the driver's introduction in the pre-git history tree introduced in v2.6.11 by 91808d6ebe39 (\"[PATCH] FRV: Add FDPIC ELF binary format driver\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68153", "url": "https://ubuntu.com/security/CVE-2026-68153", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: remove debugfs files before client teardown ceph_destroy_client() tears down the monitor client before removing the per-client debugfs files. A concurrent read of the monmap debugfs file can enter monmap_show() after ceph_monc_stop() has freed monc->monmap, triggering a use-after-free. Remove the debugfs files before stopping the OSD and monitor clients. debugfs_remove() drains active handlers and prevents new accesses, so the debugfs callbacks can no longer race the rest of client teardown.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68154", "url": "https://ubuntu.com/security/CVE-2026-68154", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: reject zero bucket types in crush_decode CRUSH bucket type 0 is reserved for devices. The mapper relies on that invariant and uses type 0 to identify leaf devices. If crush_decode() accepts a bucket with type 0, a malformed CRUSH map can make the mapper treat a negative bucket ID as a device and pass it to is_out(), which then indexes the OSD weight array with a negative value. Reject zero bucket types while decoding the CRUSH map so the invalid state never reaches the mapper.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68155", "url": "https://ubuntu.com/security/CVE-2026-68155", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: Reject monmaps advertising zero monitors A message of type CEPH_MSG_MON_MAP contains a monmap that is sent from a monitor to the client. This monmap contains information about the existing monitors in the cluster. Currently, a monmap indicating that there are zero monitors in the cluster is treated as valid. However, it is impossible to have zero monitors in the cluster and still receive a valid monmap from a monitor. Therefore, such a monmap must be corrupted and should be treated as invalid. Furthermore, a monmap with a monitor count of zero can subsequently crash the client when attempting to open a session with a monitor in __open_session(). This happens because the \"BUG_ON(monc->monmap->num_mon < 1)\" assertion in pick_new_mon() is triggered. This patch extends a check in ceph_monmap_decode() to also reject arriving mon_maps with num_mon == 0 rather than only with num_mon > CEPH_MAX_MON. [ idryomov: drop \"log output for unusual values of num_mon\" part ]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68156", "url": "https://ubuntu.com/security/CVE-2026-68156", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: refresh auth->authorizer_buf{,_len} after authorizer update ceph_x_create_authorizer() caches au->buf->vec.iov_base and au->buf->vec.iov_len in struct ceph_auth_handshake. These cached values are then used by the messenger connect code when sending the authorizer. ceph_x_update_authorizer() can rebuild the authorizer when a newer service ticket is available. If the rebuilt authorizer no longer fits in the existing buffer, ceph_x_build_authorizer() drops its reference to au->buf and allocates a new one. If this is the final reference, ceph_buffer_put() frees the old ceph_buffer and its vec.iov_base, but auth->authorizer_buf still points at that freed memory. A subsequent msgr1 reconnect can therefore queue the stale pointer and trigger a KASAN slab-use-after-free in _copy_from_iter() while tcp_sendmsg() copies the authorizer. Refresh auth->authorizer_buf and auth->authorizer_buf_len after a successful authorizer rebuild so the messenger sends the current buffer.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68157", "url": "https://ubuntu.com/security/CVE-2026-68157", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: guard missing CRUSH type name lookup Localized read selection can walk a parent bucket whose name exists in the CRUSH map while its type has no matching entry in type_names. get_immediate_parent() then dereferences a NULL type_cn and passes an invalid pointer into strcmp(), causing a null-ptr-deref. Skip such malformed parent buckets unless both the bucket name and type name metadata are present. This keeps malformed hierarchy data from crashing locality lookup and safely falls back to \"not local\". [ idryomov: add WARN_ON_ONCE ]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68158", "url": "https://ubuntu.com/security/CVE-2026-68158", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: Fix multiplication overflow in decode_new_up_state_weight() If a message of type CEPH_MSG_OSD_MAP contains a (maliciously) corrupted osdmap, out-of-bounds memory accesses may occur in decode_new_up_state_weight(). This happens because the bounds check for the new_state part is based on calculating its length depending on a len value read from the incoming message. This calculation may overflow leading to an incorrect bounds check. Subsequently, out-of-bounds reads may occur when decoding this part. This patch switches the multiplication to use check_mul_overflow() to abort processing the osdmap if an overflow occurred. Therefore, osdmaps/messages containing large values for len that result in a multiplication overflow are treated as invalid. [ idryomov: rename new_state_len -> new_state_item_size, formatting ]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68433", "url": "https://ubuntu.com/security/CVE-2026-68433", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: libceph: bound get_version reply decode to front len handle_get_version_reply() uses msg->front_alloc_len as the decode boundary for MON_GET_VERSION_REPLY. That is the size of the reused reply buffer, not the number of bytes actually received. A truncated reply can therefore pass ceph_decode_need() and decode the second u64 from stale tail bytes left in the buffer by an earlier message, causing an uninitialized memory read. Use msg->front.iov_len as the receive-side decode boundary, matching other libceph reply handlers and limiting decoding to the bytes that were actually read from the wire.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68160", "url": "https://ubuntu.com/security/CVE-2026-68160", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: fix pre-auth out-of-bounds read on snaptrace in ceph_handle_caps() ceph_handle_caps() reads snap_trace_len from the wire-format ceph_mds_caps header and uses it unconditionally to build a fake end pointer (snaptrace + snaptrace_len) that is later handed to ceph_update_snap_trace() in the CEPH_CAP_OP_IMPORT case: snaptrace = h + 1; snaptrace_len = le32_to_cpu(h->snap_trace_len); p = snaptrace + snaptrace_len; ... case CEPH_CAP_OP_IMPORT: if (snaptrace_len) { ... if (ceph_update_snap_trace(mdsc, snaptrace, snaptrace + snaptrace_len, false, &realm)) { ... } ceph_update_snap_trace() then decodes a struct ceph_mds_snap_realm from snaptrace using ceph_decode_need(&p, e, sizeof(*ri), bad) with the attacker-supplied fake end e == snaptrace + snaptrace_len. With snaptrace_len == 0xFFFFFFFF the bound check is trivially satisfied, ri = p reads sizeof(struct ceph_mds_snap_realm) past the legitimate msg->front buffer, and ri->num_snaps / ri->num_prior_parent_snaps then drive further out-of-bounds reads of the encoded snap arrays. The eleven msg_version >= 2 .. msg_version >= 12 decoder blocks above the op switch each catch this OOB through their ceph_decode_*_safe() / ceph_decode_need() helpers, but they sit behind a hdr.version-gated if, so a malicious or compromised MDS that sets msg->hdr.version = 1 reaches the IMPORT path with no version-gated decoder having validated snap_trace_len. The shape has been present since ceph_handle_caps() was introduced. Validate snap_trace_len against the message front buffer before consuming it, using the canonical ceph_decode_need() / ceph_has_room() helper. The helper bounds the length with subtraction (n <= end - p, guarded by end >= p) rather than pointer addition, so it is wrap-safe for the attacker-controlled u32 length on 32-bit builds where p + snap_trace_len could overflow the address space. This matches the rest of the ceph decode path (e.g. the pool_ns_len check a few lines below), and the existing goto bad cleanup already covers this exit path.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68175", "url": "https://ubuntu.com/security/CVE-2026-68175", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix resource leak on mmiotrace trace_pipe close The mmiotrace tracer was added May 12th 2008. At that time, resources created in pipe_open() could not be freed because there was not pipe_close function pointer of the tracer. The pipe_close function pointer was added in December 7th, 2009, but the mmiotrace tracer was not updated. mmio_pipe_open() allocates a header_iter and takes a pci_dev reference when trace_pipe is opened. mmio_close() frees them, but it was only wired to the tracer's .close callback. tracing_release_pipe() invokes .pipe_close, not .close, when the trace_pipe file is released. As a result, closing trace_pipe with the mmiotrace tracer active leaked the header_iter allocation and left a stale pci_dev reference. Set .pipe_close to mmio_close, matching how function_graph wires both callbacks to the same handler. Note, if the trace_pipe is read to completion, it will clean up the resources, but if one were to run: # head -n 1 /sys/kernel/tracing/trace_pipe VERSION 20070824 Over and over again, it would trigger a massive leak.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68176", "url": "https://ubuntu.com/security/CVE-2026-68176", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing: Fix mmiotrace possible NULL dereferencing of hiter->dev If the mmio_pipe_open() fails to find a PCI device, the hiter->dev will be assigned to NULL. The mmiotrace read() function dereferences the hiter->dev if hiter exists. Change the test of the read to not only check hiter being NULL, but also the hiter->dev before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68180", "url": "https://ubuntu.com/security/CVE-2026-68180", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: intel_th: fix MSC output device reference leak intel_th_output_open() looks up the output device with bus_find_device_by_devt(), which returns the device with a reference that must be dropped after use. commit 95fc36a234da (\"intel_th: fix device leak on output open()\") attempted to drop the reference from intel_th_output_release(). However, a successful open replaces file->f_op with the output driver file operations before returning, so close runs the output driver release callback instead. For MSC outputs, close runs intel_th_msc_release(), which only removes the per-file iterator and does not drop the device reference taken by intel_th_output_open(). Consequently, every successful MSC output open leaks one device reference. Drop the device reference from intel_th_msc_release(), which is the release path actually used for MSC output files. Remove the now-unused intel_th_output_release() callback from intel_th_output_fops.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68181", "url": "https://ubuntu.com/security/CVE-2026-68181", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mei: bus: access mei_device under device_lock on cleanup Fix couple of problems in mei_cl_bus_dev_release(): mei_cl_flush_queues() is running without lock. bus->file_list access after mei_dev_bus_put(bus) can become a use-after-free if this was the last reference to bus. Protect queues cleanup and WARN traversal by device lock there to avoid the concurrent access problems. Move WARN traversal before mei_dev_bus_put(bus). This file uses bus variable name for mei_device, adjust code of mei_cl_bus_dev_release() to use bus variable too.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68182", "url": "https://ubuntu.com/security/CVE-2026-68182", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: comedi: comedi_parport: deal with premature interrupt Syzbot reported a general protection fault in `comedi_get_is_subdevice_running()`, which was called from the interrupt handler `parport_interrupt()` in the \"comedi_parport\" driver, but it does not currently have a C reproducer for the problem. It's probably due to a premature interrupt for one of two reasons: 1. The driver sets up the interrupt handler before the comedi subdevices used by the interrupt handler have been allocated, but does not disable the interrupt in the parallel port's CTRL register first. 2. The driver uses a user-supplied I/O port base address which Syzbot would have supplied, but it might not be backed by real parallel port hardware. Change the initialization order in the driver's comedi \"attach\" handler (`parport_attach()`) so that the hardware registers are initialized before the interrupt handler is requested. This should prevent premature interrupts occurring for real hardware. Also add a test to the interrupt handler to ensure the comedi device is fully attached and return early if it isn't.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68184", "url": "https://ubuntu.com/security/CVE-2026-68184", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cdrom: fix stack out-of-bounds read in CDROMVOLCTRL mmc_ioctl_cdrom_volume() first reads the audio control mode page into a 32-byte stack buffer with cgc->buflen set to 24. If the device reports a block descriptor, the function increases cgc->buflen to include that descriptor and reads the page again. For CDROMVOLCTRL, the function then builds a MODE SELECT parameter list by moving cgc->buffer forward by offset - 8 bytes. This drops the block descriptor from the outgoing payload and leaves a new 8-byte mode parameter header in front of the audio control page. However, cgc->buflen is left unchanged. With a standard 8-byte block descriptor, cgc->buffer points at buffer + 8 but cgc->buflen remains 32. cdrom_mode_select() therefore asks the low level packet path to write 32 bytes from that adjusted pointer, reading 8 bytes past the end of the 32-byte stack buffer. This is not hit by CDROMVOLREAD, and CDROMVOLCTRL only triggers it on drives that return a non-zero block descriptor length, which helps explain why it has gone unnoticed. The overread is also sent to the device as extra MODE SELECT payload, so it may not produce an obvious local failure. Reduce cgc->buflen by the same amount as the buffer pointer adjustment so the MODE SELECT transfer covers only the intended parameter list.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68186", "url": "https://ubuntu.com/security/CVE-2026-68186", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: binfmt_misc: set have_execfd only once the interpreter is opened load_misc_binary() raises bprm->have_execfd as soon as it sees the 'O' (or 'C') flag. This happens well before it opens the interpreter. If that open fails the flag stays set on the bprm. binfmt_misc is at the head of the format list so an interpreter open failure that returns -ENOEXEC lets the search fall through to a later format. This means it runs the matched binary directly having never staged an interpreter. So bprm->executable is NULL while have_execfd falsely claims a descriptor is present. Consequently, begin_new_exec() dereferences the missing executable: would_dump(bprm, bprm->executable); and NULL derefs. Had it not, the hand-off later in the same function would have failed anyway. FD_ADD(0, bprm->executable) rejects a NULL file with -ENOMEM. Both sites are past the point of no return so the exec cannot be unwound either way. This can be reached by unprivileged users as binfmt_misc can be mounted in user namespaces. So a user can register an 'O' entry whose interpreter lives on a FUSE mount, have the FUSE server fail the open with -ENOEXEC and execute a native ELF file that matches the entry. have_execfd only means anything alongside the executable it describes which is not set until the interpreter has been opened and staged. So lets raise it there, next to execfd_creds, which is already set at that point. An open failure now leaves it clear, so the fallback format derives credentials from the binary and emits no AT_EXECFD, as it would for any native exec. The argv rewrite load_misc_binary() performs before the open is still not undone. This means the binary sees the interpreter path in argv[0] and its own path in argv[1] but that predates this change and only became observable once the exec stopped faulting.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68187", "url": "https://ubuntu.com/security/CVE-2026-68187", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exec: fix unsigned loop counter wrap in transfer_args_to_stack() The stop value is derived from bprm->p >> PAGE_SHIFT. The index variable is an unsigned long. If bprm->p drops below PAGE_SIZE and stop becomes zero the loop condition index >= stop is always true. After the index == 0 iteration the decrement wraps to ULONG_MAX and bprm->page[ULONG_MAX] reads sizeof(void *) bytes in front of the array. The pointer has wrapped to -1. That garbage pointer is then passed to kmap_local_page() and PAGE_SIZE bytes are copied from wherever that lands into the stack of the process being created. And the loop doesn't terminate either... Getting there only requires bprm->p < PAGE_SIZE. On !MMU bprm_set_stack_limit() and bprm_hit_stack_limit() are empty. So the only constraint on how far bprm->p is pushed down is valid_arg_len(), i.e. that each individual string still fits in what is left. bprm->p starts at PAGE_SIZE * MAX_ARG_PAGES - sizeof(void *) so a single argument or environment string of a little over 31 pages leaves it in the first page: Oops - load access fault [#1] CPU: 0 UID: 0 PID: 1 Comm: victim Not tainted 7.2.0-rc4 #1 epc : __memcpy+0xd4/0xf8 ra : transfer_args_to_stack+0xaa/0xae s4 : ffffffffffffffff s2 : 0000000000000000 a1 : ffffffdc98000000 a2 : 0000000000001000 status: 0000000a00001880 badaddr: ffffffdc98000000 cause: 0000000000000005 [<801a5324>] __memcpy+0xd4/0xf8 [<800d5f6a>] load_flat_binary+0x43a/0x65e [<800a2de4>] bprm_execve+0x1d4/0x316 [<800a351a>] do_execveat_common+0x12e/0x138 [<800a3d44>] __riscv_sys_execve+0x38/0x4e Kernel panic - not syncing: Fatal exception in interrupt This is an arcane bug but we should still fix it. Count down from MAX_ARG_PAGES so the loop ends when index reaches stop, stop == 0 included. The iterations performed are unchanged for every other value of stop. Only CONFIG_MMU=n builds are affected, transfer_args_to_stack() is used by binfmt_flat and binfmt_elf_fdpic on nommu only. The loop predates git history. commit 7e7ec6a93434 (\"elf_fdpic_transfer_args_to_stack(): make it generic\") only moved it from binfmt_elf_fdpic.c into fs/exec.c and narrowed the copy to the used part of the first page. The condition and the decrement are unchanged from 2.6.12-rc2.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68188", "url": "https://ubuntu.com/security/CVE-2026-68188", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: Fix session UAF in set_termios rfcomm_tty_set_termios() tests dlc->session without rfcomm_mutex and later passes the pointer to rfcomm_send_rpn(). The latter dereferences both session->initiator and session->sock. Meanwhile, krfcommd can unlink the DLC and free the session while holding rfcomm_mutex. The race can proceed as follows: TTY ioctl task krfcommd -------------- -------- load dlc->session enter rfcomm_send_rpn() lock rfcomm_mutex clear dlc->session free session unlock rfcomm_mutex read session->initiator KASAN reported: BUG: KASAN: slab-use-after-free in rfcomm_send_rpn+0x297/0x2a0 Read of size 4 at addr ffff88810012a850 by task poc/92 Call Trace: rfcomm_send_rpn+0x297/0x2a0 rfcomm_tty_set_termios+0x50d/0x850 tty_set_termios+0x596/0x950 set_termios+0x46a/0x6e0 tty_mode_ioctl+0x152/0xbd0 tty_ioctl+0x915/0x1240 __x64_sys_ioctl+0x134/0x1c0 Allocated by task 92: rfcomm_session_add+0x9e/0x2e0 rfcomm_dlc_open+0x8b1/0xe00 rfcomm_dev_activate+0x85/0x1a0 rfcomm_tty_open+0x90/0x280 Freed by task 68: kfree+0x131/0x3c0 rfcomm_session_del+0x119/0x180 rfcomm_run+0x737/0x4710 Add rfcomm_dlc_send_rpn(), which holds rfcomm_mutex while it verifies that the DLC is still attached and sends the RPN frame. Have the TTY path use the helper and drop its unlocked session check. This keeps the session valid through both the frame construction and socket send.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68189", "url": "https://ubuntu.com/security/CVE-2026-68189", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: Protect UUID list traversal The hci_sync conversion moved class-of-device and EIR generation from an HCI request built under hdev->lock to asynchronous command sync work. The worker holds hdev->req_lock, but that lock does not serialize access to hdev->uuids against add_uuid() and remove_uuid(), which update the list under hdev->lock. The following interleaving can therefore occur: CPU0 (command sync work) CPU1 (management socket) fetch uuid from the list list_del(&uuid->list) kfree(uuid) read uuid->size KASAN reports the resulting use-after-free: BUG: KASAN: slab-use-after-free in eir_create+0xb8f/0xee0 Read of size 1 at addr ffff88810dbd8620 by task kworker/u17:0/87 Workqueue: hci0 hci_cmd_sync_work Call Trace: eir_create+0xb8f/0xee0 hci_update_eir_sync+0x1c0/0x330 hci_cmd_sync_work+0x13c/0x290 process_one_work+0x63a/0x1070 worker_thread+0x45b/0xd10 Allocated by task 86: __kasan_kmalloc+0x8f/0xa0 add_uuid+0x18a/0x4b0 hci_sock_sendmsg+0x1033/0x1ea0 Freed by task 92: __kasan_slab_free+0x43/0x70 kfree+0x131/0x3c0 remove_uuid+0x25e/0x560 hci_sock_sendmsg+0x1033/0x1ea0 Hold hdev->lock while generating and committing the class-of-device and EIR snapshots. Release it before sending an HCI command, so controller waits do not happen under the device lock. This protects all UUID list walks in these paths and restores the serialization lost in the command sync conversion.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68190", "url": "https://ubuntu.com/security/CVE-2026-68190", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix OOB reads in rtw_get_wps_ie() rtw_get_wps_ie() iterates over IE data from network frames without validating that the IE header and payload fit within the remaining buffer before reading them. Specifically: - in_ie[cnt + 1] is read without checking cnt + 1 < in_len - memcmp(&in_ie[cnt + 2], ...) accesses cnt + 2 without bounds check - in_ie[cnt + 1] is used as length without verifying payload fits Add bounds checks at the top of the loop body to break early if fewer than 2 bytes remain for the IE header, or if the declared payload extends past the end of the buffer. Also require at least 4 bytes of payload before comparing the WPS OUI.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68192", "url": "https://ubuntu.com/security/CVE-2026-68192", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: make release_scratchbuffers idempotent brcmf_pcie_release_scratchbuffers() frees the shared.scratch and shared.ringupd DMA buffers with dma_free_coherent() but does not clear the pointers afterwards, unlike the sibling release_ringbuffers() which NULLs commonrings/flowrings/idxbuf on release. Both the bus_reset .reset callback (brcmf_pcie_reset) and brcmf_pcie_remove() call release_scratchbuffers. When reset teardown has run before removal, remove's own teardown would call dma_free_coherent() a second time on the already-freed DMA allocation. NULL the pointers after free, matching release_ringbuffers(), so a later release observes that the allocation has already been released. This patch makes repeated sequential release safe; the reset-work lifetime is handled separately by the following patch. This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68194", "url": "https://ubuntu.com/security/CVE-2026-68194", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7921: drop TXRX_NOTIFY on non-mmio buses PKT_TYPE_TXRX_NOTIFY is an mmio-only event, but mt7921_rx_check() and mt7921_queue_rx_skb() dispatch it to mt7921_mac_tx_free() on every bus. mt7921_mac_tx_free() cleans the DMA tx queues with mt76_queue_tx_cleanup(), which calls queue_ops->tx_cleanup(). Only the mmio queue ops implement that callback; on USB and SDIO it is NULL, so a TXRX_NOTIFY there calls a NULL pointer in the RX worker: BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:0x0 Call Trace: mt7921_mac_tx_free+0x64/0x310 [mt7921_common] mt7921_rx_check+0x5f/0xf0 [mt7921_common] mt76u_rx_worker+0x1b9/0x620 [mt76_usb] Drop the event on non-mmio buses via mt76_is_mmio(), as in commit 5683e1488aa9 (\"wifi: mt76: connac: do not check WED status for non-mmio devices\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68195", "url": "https://ubuntu.com/security/CVE-2026-68195", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7615: drop TXRX_NOTIFY on non-mmio buses PKT_TYPE_TXRX_NOTIFY is an mmio-only event, but mt7615_rx_check() and mt7615_queue_rx_skb() dispatch it to mt7615_mac_tx_free() on every bus. mt7615_mac_tx_free() cleans the DMA tx queues with mt76_queue_tx_cleanup(), which calls queue_ops->tx_cleanup(). Only the mmio queue ops implement that callback; on the mt7663 USB and SDIO buses it is NULL, so a TXRX_NOTIFY there calls a NULL pointer in the RX worker. Same defect as the mt7921 and mt7925 patches in this series. Drop the event on non-mmio buses via mt76_is_mmio(), as in commit 5683e1488aa9 (\"wifi: mt76: connac: do not check WED status for non-mmio devices\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68196", "url": "https://ubuntu.com/security/CVE-2026-68196", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: wilc1000: validate assoc response length before subtracting header wilc_parse_assoc_resp_info() computes the trailing IE length as \ties_len = buffer_len - sizeof(*res); without first checking that buffer_len is at least sizeof(struct wilc_assoc_resp) (6 bytes). buffer_len is the length reported for a received association response (host_int_parse_assoc_resp_info() passes hif_drv->assoc_resp / assoc_resp_info_len straight in) and must be validated before the driver accesses the fixed header. For a frame shorter than the 6-byte fixed header, the subtraction wraps. For a four-byte response the result is truncated to a u16 ies_len of 65534, so kmemdup() then attempts to copy 65534 bytes starting at buffer + sizeof(*res), beyond the valid association-response data (CWE-125). A response shorter than four bytes can also cause an out-of-bounds read of res->status_code at offsets 2 and 3. Reject frames too short to hold the fixed header before touching the header or computing ies_len. Also set the connection status to a failure on this path: the caller falls through to a \"conn_info->status == WLAN_STATUS_SUCCESS\" check after the parser returns, so leaving the status untouched could let a malformed short response be treated as a successful association.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68197", "url": "https://ubuntu.com/security/CVE-2026-68197", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: fix NULL dereference when the AP has HT-cap but no HT-oper mwifiex_tdls_add_ht_oper() gates its follow-the-AP-bandwidth path on bss_desc->bcn_ht_cap being present, but then dereferences a different pointer, bss_desc->bcn_ht_oper: \tif (ISSUPP_CHANWIDTH40(priv->adapter->hw_dot_11n_dev_cap) && \t bss_desc->bcn_ht_cap && \t ISALLOWED_CHANWIDTH40(bss_desc->bcn_ht_oper->ht_param)) bcn_ht_cap and bcn_ht_oper are populated independently while parsing the associated AP's beacon in mwifiex_update_bss_desc_with_ie(): an AP that advertises an HT Capabilities element but no HT Operation element leaves bcn_ht_cap non-NULL and bcn_ht_oper NULL. Setting up a TDLS link to a peer while associated to such an AP then dereferences the NULL bcn_ht_oper and crashes the kernel. Every other bcn_ht_oper user in the driver NULL-checks it first. Guard on the pointer that is actually dereferenced. Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68199", "url": "https://ubuntu.com/security/CVE-2026-68199", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: fix OOB access from firmware ADDBA window size aggr_recv_addba_req_evt() logs a debug message when the firmware-supplied win_sz is outside [AGGR_WIN_SZ_MIN, AGGR_WIN_SZ_MAX] but does not return. The out-of-range win_sz is then used in TID_WINDOW_SZ() to compute a kzalloc size and stored in rxtid->hold_q_sz, leading to zero-size or overflowed allocations and subsequent out-of-bounds access. Clean up any previously active aggregation session for the TID first, then return early when win_sz is out of the valid range, instead of proceeding with a broken allocation size.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68202", "url": "https://ubuntu.com/security/CVE-2026-68202", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: seq: close a re-opened queue timer in the destructor queue_delete() closes the queue timer, then frees it. snd_seq_timer_close() clears q->timer->timeri. snd_use_lock_sync() then drains borrowers, and snd_seq_timer_delete() frees q->timer. A borrower can re-open the timer inside that window. A SET_QUEUE_CLIENT that took a queueptr() use_lock reference before the queue was unlinked runs snd_seq_timer_open() after the close. Open refuses re-open only while timeri is set, and the close just cleared it, so it re-opens timeri. snd_seq_timer_delete() does not close that instance. Its snd_seq_timer_stop() is a no-op, because running was cleared first. So it frees q->timer with the instance still live. The queue is freed next. The instance stays on the global timer with callback_data pointing at the freed queue. A non-owner START on the unlocked queue arms it. The next tick derefs the freed queue in snd_seq_timer_interrupt(). Reachable by an unprivileged user with access to /dev/snd/seq. No CAP and no queue ownership required. Close any lingering instance in the destructor. There, ->timeri can no longer change: the queue is unlinked and all use_lock borrowers have drained, so no snd_seq_queue_use() can re-open it. Close it before clearing q->timer. snd_timer_close() waits for any in-flight snd_seq_timer_interrupt() to finish, and that callback still reads q->timer (via snd_seq_check_queue()), so q->timer must stay valid until it drains.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68204", "url": "https://ubuntu.com/security/CVE-2026-68204", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: vivid: check for vb2_is_busy() when toggling caps The vivid_update_format_cap/out() functions must only be called if the capture/output queue are not busy. But for the controls that select the CROP/COMPOSE/SCALE capability that is not checked. Only when streaming starts will they be set to 'grabbed' and it is impossible to change the control, but between REQBUFS and STREAMON you are still allowed to set these controls. Since vivid_update_format_cap/out will change the format, this can cause unexpected results. Besides adding these checks, also add a WARN_ON in vivid_update_format_cap/out() if the queue is busy. I'm 90% certain that this is the cause of this syzbot bug: https://syzkaller.appspot.com/bug?extid=dac8f5eaa46837e97b89 But since we never have reproducers, it is hard to be certain. In any case, these checks are needed regardless.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68206", "url": "https://ubuntu.com/security/CVE-2026-68206", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: v4l2-ctrls: validate HEVC active reference counts HEVC slice parameters are shared stateless V4L2 controls, but the common validation path does not verify the active L0/L1 reference counts before driver-specific code consumes them. The original report came from Cedrus, but the active count bounds are not Cedrus-specific. Validate them in the common HEVC slice control path so stateless HEVC drivers get the same basic guarantees as soon as the control is queued. Do not reject ref_idx_l0/ref_idx_l1 entries here. Existing userspace may use out-of-range sentinel values such as 0xff for missing references, and some hardware can use that information for concealment. Keep this common check limited to the active reference counts.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68207", "url": "https://ubuntu.com/security/CVE-2026-68207", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: ti: vpe: unwind v4l2 device registration on probe error If the vpe_top resource is missing, vpe_probe() returns -ENODEV after v4l2_device_register() has succeeded. Probe failures do not call the driver's remove callback, so the v4l2 device remains registered on that error path. Route that failure through the existing v4l2_device_unregister() unwind label, matching the other errors after v4l2_device_register().", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68209", "url": "https://ubuntu.com/security/CVE-2026-68209", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: sun4i-csi: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. sun4i_csi_start_streaming() returned -EINVAL when no matching CSI format could be found, before any setup (scratch buffer allocation, pipeline start) had been performed. The remaining error paths already converge on the err_clear_dma_queue label, which calls return_all_buffers(..., VB2_BUF_STATE_QUEUED) under csi->qlock. Jump to that label directly: the intermediate err_disable_device / err_disable_pipeline / err_free_scratch_buffer labels are skipped, which is correct because nothing they would undo has happened yet. This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68210", "url": "https://ubuntu.com/security/CVE-2026-68210", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: stm32: dcmi: unregister notifier on probe failure dcmi_graph_init() registers the async notifier before dcmi_probe() toggles the reset line. If reset_control_assert() or reset_control_deassert() fails afterwards, probe returns through err_cleanup and the driver core will not call dcmi_remove(). Unregister the notifier before cleaning it up on that error path, matching the successful remove path and the V4L2 async notifier lifetime rules. [hverkuil: added Fixes tag]", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68212", "url": "https://ubuntu.com/security/CVE-2026-68212", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: saa7134: Fix a possible memory leak in saa7134_video_init1 In saa7134_video_init1(), the return value of the first saa7134_pgtable_alloc() is not checked. If it fails, the function continues as if successful, leaving the driver with an invalid page table. Additionally, if vb2_queue_init() for the VBI queue fails after the video queue page table has been allocated, the allocated memory is not freed before returning. The second saa7134_pgtable_alloc() also lacks a return value check. Errors occur during device probing before the device is fully registered, the normal cleanup path in saa7134_finidev() is not executed, leading to memory leaks and potential use of uninitialized DMA resources. Check the return value of both saa7134_pgtable_alloc() calls and propagate errors. On failure of any later step, free allocated page tables to avoid memory leaks. Ensure control handlers are also released on error to prevent further resource leakage. Found by code review.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68213", "url": "https://ubuntu.com/security/CVE-2026-68213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: rtl2832_sdr: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. rtl2832_sdr_start_streaming() had multiple error paths that hit this trap: two direct early returns (-ENODEV, -ERESTARTSYS), plus six `goto err` paths covering subdev s_power, tuner setup, ADC setup, stream-buffer allocation, urb allocation, and urb submission failures. None of them returned the queued buffers. The original function had no distinct success exit and fell straight through into the err label, which previously only did mutex_unlock and \"return ret\". Adding queued-buffer cleanup at err must therefore be paired with an explicit success return; otherwise every successful start would also drain the buffer queue and kill streaming. Add that success return, then add rtl2832_sdr_cleanup_queued_bufs() at the err label and before each early return. The cleanup helper takes a vb2_buffer_state argument so that the start_streaming error paths can pass VB2_BUF_STATE_QUEUED (as expected by userspace on start_streaming failure) while stop_streaming keeps its existing VB2_BUF_STATE_ERROR semantics. This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\"). The err label still does not roll back power_ctrl(), frontend_ctrl(), the POWER_ON flag, or stream/URB allocations that may have happened before the failing step. Those are pre-existing leaks of a different class and are not addressed here.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68214", "url": "https://ubuntu.com/security/CVE-2026-68214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: rtl2832: fix use-after-free in rtl2832_remove() cancel_delayed_work_sync() is called before i2c_mux_del_adapters() in rtl2832_remove(). While the cancel waits for any running instance of i2c_gate_work to finish, it does not prevent the timer from being rescheduled by a concurrent thread. During probe, the r820t_attach() call attempts I2C transfers through the mux adapter. These transfers go through i2c_mux_master_xfer(), which calls rtl2832_deselect() after the transfer completes, rescheduling i2c_gate_work via schedule_delayed_work(). If this transfer is still in flight when rtl2832_remove() runs, rtl2832_deselect() can reschedule i2c_gate_work after it has been cancelled, causing a use-after-free when kfree(dev) is called. Fix this by calling i2c_mux_del_adapters() before cancel_delayed_work_sync(). Once the mux adapter is unregistered, no new I2C transfers can go through it, so rtl2832_deselect() can no longer reschedule i2c_gate_work. The subsequent cancel_delayed_work_sync() is then guaranteed to be final.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68215", "url": "https://ubuntu.com/security/CVE-2026-68215", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: radio-si476x: Unregister v4l2_device on probe failure si476x_radio_probe() registers radio->v4l2dev before allocating the V4L2 controls and before registering the video device. If any of those later steps fails, probe returns through the exit label after freeing only the control handler. A failed probe does not call si476x_radio_remove(), so the v4l2_device_unregister() there is not reached. This leaves the parent device reference taken by v4l2_device_register() behind on the error path. Unregister the V4L2 device in the probe error path after freeing the controls.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68216", "url": "https://ubuntu.com/security/CVE-2026-68216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: pwc: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. pwc's start_streaming() had two early returns that hit this trap: -ENODEV when the USB device was already disconnected, and -ERESTARTSYS when mutex_lock_interruptible() was interrupted by a signal. Call the existing pwc_cleanup_queued_bufs() helper with VB2_BUF_STATE_QUEUED before returning (matching the state already used by the pwc_isoc_init() error path in the same function). This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68217", "url": "https://ubuntu.com/security/CVE-2026-68217", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: pwc: Drain fill_buf on start_streaming() failure pwc_isoc_init() submits its isochronous URBs with usb_submit_urb(.., GFP_KERNEL) in a loop. After the first URB is submitted, its completion handler pwc_isoc_handler() can run on another CPU before the loop finishes: start_streaming() pwc_isoc_init() usb_submit_urb(urbs[0], GFP_KERNEL) pwc_isoc_handler(urbs[0]) pdev->fill_buf = pwc_get_next_fill_buf(pdev) usb_submit_urb(urbs[i>0], ..) -> fails pwc_isoc_cleanup(pdev) /* kills URBs */ return ret; pwc_cleanup_queued_bufs(pdev, VB2_BUF_STATE_QUEUED) pwc_get_next_fill_buf() detaches a buffer from pdev->queued_bufs and stores it in pdev->fill_buf. The error path in start_streaming() only drains pdev->queued_bufs, so the buffer parked in pdev->fill_buf is leaked. vb2_start_streaming() then triggers WARN_ON(owned_by_drv_count). stop_streaming() already handles this since commit 80b0963e1698 (\"[media] pwc: fix WARN_ON\"), which added the fill_buf drain in the teardown path but not in the start_streaming() error path. Mirror that handling on failure so start_streaming() returns with no buffer owned by the driver. Issue identified by automated review of the INV-003 series at https://sashiko.dev/", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68218", "url": "https://ubuntu.com/security/CVE-2026-68218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: pci: dm1105: Free allocated workqueue Destroy allocated workqueue in remove() callback to free its resources, thus fixing memory leak.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68219", "url": "https://ubuntu.com/security/CVE-2026-68219", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: nxp: imx8-isi: Fix potential out-of-bounds issues The maximum downscaling factor supported by ISI can be up to 16. Add minimum value constraint before applying the setting to hardware. Otherwise, the process will not respond even when Ctrl+C is executed.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68220", "url": "https://ubuntu.com/security/CVE-2026-68220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: nxp: imx8-isi: Add missing v4l2_subdev_cleanup() in crossbar and pipe Both mxc_isi_crossbar_init() and mxc_isi_pipe_init() call v4l2_subdev_init_finalize() which allocates the subdev active state, but neither mxc_isi_crossbar_cleanup() nor mxc_isi_pipe_cleanup() calls v4l2_subdev_cleanup() to free it. This causes a memory leak on every rmmod, reported by kmemleak: unreferenced object 0xffff0000d06fc800 (size 192): comm \"(udev-worker)\", pid 254, jiffies 4294913455 backtrace (crc 36eeae58): kmemleak_alloc+0x34/0x40 __kvmalloc_node_noprof+0x5f8/0x7d8 __v4l2_subdev_state_alloc+0x1fc/0x30c __v4l2_subdev_init_finalize+0x178/0x368 Add the missing v4l2_subdev_cleanup() calls before media_entity_cleanup() in both crossbar and pipe cleanup paths.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68222", "url": "https://ubuntu.com/security/CVE-2026-68222", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: msi2500: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. msi2500_start_streaming() had five error paths that all hit this trap and were further tangled by ret-overwriting between calls: - -ENODEV when the USB device was already disconnected - -ERESTARTSYS when mutex_lock_interruptible() was interrupted - msi2500_set_usb_adc() failure: ret was silently overwritten by the next call (msi2500_isoc_init), so the error was lost entirely - msi2500_isoc_init() failure: cleanup_queued_bufs was called, but the function then fell through to msi2500_ctrl_msg() and again masked the original error by overwriting ret - msi2500_ctrl_msg(CMD_START_STREAMING) failure: no cleanup at all, leaving isoc URBs submitted with no way for the driver to consume them Consolidate the error paths into a small goto chain. Every failure now stops the function, drains the queued-buffer list, and returns the real error code. The ctrl_msg failure path also rolls back the preceding msi2500_isoc_init() via msi2500_isoc_cleanup() before unlocking and draining. The cleanup helper takes a vb2_buffer_state argument so that the start_streaming error paths can pass VB2_BUF_STATE_QUEUED (as expected by userspace on start_streaming failure) while stop_streaming keeps its existing VB2_BUF_STATE_ERROR semantics. This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68223", "url": "https://ubuntu.com/security/CVE-2026-68223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: meson: vdec: Fix memory leak in error path of vdec_open The vdec_open() function previously jumped directly to err_m2m_release when vdec_init_ctrls() failed, skipping release of the m2m context. This caused a resource leak. Fix it by introducing a proper err_m2m_ctx_release label that calls v4l2_m2m_ctx_release(sess->m2m_ctx) before releasing the m2m device. This was identified via kmemleak: unreferenced object 0xffff0000205d6878 (size 8): comm \"v4l_id\", pid 5289, jiffies 4294938580 hex dump (first 8 bytes): 40 d2 49 18 00 00 ff ff @.I..... backtrace (crc d3204599): kmemleak_alloc+0xc8/0xf0 __kvmalloc_node_noprof+0x60c/0x850 v4l2_ctrl_handler_init_class+0x1b4/0x2e8 [videodev] vdec_open+0x1f4/0x788 [meson_vdec] v4l2_open+0x144/0x460 [videodev] chrdev_open+0x1ac/0x500 do_dentry_open+0x3f0/0xfe8 vfs_open+0x68/0x320 do_open+0x2d8/0x9a8 path_openat+0x1d0/0x4f0 do_filp_open+0x190/0x380 do_sys_openat2+0xf8/0x1b0 __arm64_sys_openat+0x13c/0x1e8 invoke_syscall+0xdc/0x268 el0_svc_common.constprop.0+0x178/0x258 do_el0_svc+0x4c/0x70", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68226", "url": "https://ubuntu.com/security/CVE-2026-68226", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cx23885: add ioremap return check and cleanup Add a check for the return value of pci_ioremap_bar() in cx23885_dev_setup(). If ioremap for BAR0 fails, release the already allocated PCI memory region, decrement the device count, and return -ENODEV. This prevents a potential null pointer dereference and ensures proper cleanup on memory mapping failure.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68227", "url": "https://ubuntu.com/security/CVE-2026-68227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cx231xx: 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 driver state lifetime so that it is released on driver unbind.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68229", "url": "https://ubuntu.com/security/CVE-2026-68229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cedrus: skip invalid H.264 reference list entries Cedrus consumes H.264 ref_pic_list0/ref_pic_list1 entries from the stateless slice control and later uses their indices to look up decode->dpb[] in _cedrus_write_ref_list(). Rejecting such controls in cedrus_try_ctrl() would break existing userspace, since stateless H.264 reference lists may legitimately carry out-of-range indices for missing references. Instead, guard the actual DPB lookup in Cedrus and skip entries whose indices do not fit the fixed V4L2_H264_NUM_DPB_ENTRIES array. This keeps the fix local to the driver use site and avoids out-of-bounds reads from malformed or unsupported reference list entries.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68231", "url": "https://ubuntu.com/security/CVE-2026-68231", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: airspy: Return queued buffers on start_streaming() failure The vb2 framework hands buffers to the driver via buf_queue() before calling start_streaming(). If start_streaming() returns an error without first returning those buffers via vb2_buffer_done(), vb2_start_streaming() fires WARN_ON(owned_by_drv_count) and the queued buffers leak. airspy_start_streaming() returned -ENODEV early when the USB device had been disconnected (s->udev == NULL) without returning any buffers that buf_queue() had already accepted. Take v4l2_lock first and jump to the existing err_clear_bit label, which already drains s->queued_bufs via vb2_buffer_done(..., VB2_BUF_STATE_QUEUED) before unlocking. This mirrors the uvcvideo fix in commit 4cf3b6fd54eb (\"media: uvcvideo: Return queued buffers on start_streaming() failure\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68445", "url": "https://ubuntu.com/security/CVE-2026-68445", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vc4: Prevent shader BO mappings from becoming writable vc4_gem_object_mmap() rejects a writable mapping of a validated shader BO, but leaves VM_MAYWRITE set. Userspace can map the BO read-only and then turn it writable with mprotect(). Validated shader BOs must stay read-only: the validator checks the instructions once and the GPU trusts them afterwards. A writable mapping lets userspace rewrite the code after validation, bypassing the validator. Clear VM_MAYWRITE on the read-only path so the mapping cannot be upgraded, as i915 already does for its read-only objects.", "cve_priority": "high", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68446", "url": "https://ubuntu.com/security/CVE-2026-68446", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: Validate vmw_surface_metadata::array_size This field comes from userspace and should be validated against specific limits depending on which Shader Model (SM) is available.", "cve_priority": "high", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68234", "url": "https://ubuntu.com/security/CVE-2026-68234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix bo->pin leaking in amdgpu_bo_create_reserved amdgpu_bo_create_reserved() only allocates a new BO when *bo_ptr (struct amdgpu_bo **bo_ptr as input parameter) is NULL, it simply skips creation when *bo_ptr is non-NULL. But it unconditionally reserves, pins, gart allocates and maps the BO afterwards. When the same non-NULL BO pointer is passed in again, for example firmware buffers that live in adev and are re-loaded on every resume / cp_resume / start under AMDGPU_FW_LOAD_DIRECT, amdgpu_bo_pin() just increases pin_count unconditionally, however the matching teardown only unpins once, so pin_count never drops to zero, so TTM is not able to move, swap or evict a BO, causing BO leaks. This commit fixes this issue by only pinning the bo once at creation, and repeated calls no longer take additional pin references. (cherry picked from commit 3ddc0ae76202c447b6aec61e907b852bc94671cf)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68236", "url": "https://ubuntu.com/security/CVE-2026-68236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: set new_stream to NULL after release In dm_update_crtc_state(), the skip_modeset path releases new_stream via dc_stream_release() but does not set the pointer to NULL. If a later error (e.g., color management failure) triggers the fail label, the error path calls dc_stream_release() again on the same dangling pointer, causing a double release and potential use-after-free. Fix this by setting new_stream to NULL after the initial release. (cherry picked from commit 99f3af19073b3ddbfd96e789124cce12c4277b28)", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68243", "url": "https://ubuntu.com/security/CVE-2026-68243", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/gem: Fix NULL deref in I915_CONTEXT_PARAM_SSEU Setting context engine slot N into I915_ENGINE_CLASS_INVALID / I915_ENGINE_CLASS_INVALID_NONE and attempting to apply I915_CONTEXT_PARAM_SSEU to the same slot N will deref NULL. Fix that. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 36eda5b5c2d40da41cc0a5403c26986237cf9e87)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68244", "url": "https://ubuntu.com/security/CVE-2026-68244", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/gem: Do not leak siblings[] on proto context error After a successful BALANCE/PARALLEL_SUBMIT extension on context creation, error during processing of next user extension leaks the siblings[] array. Fix that. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit aa65e0a4b51b3b54b53e4142aaa2d997aa1061ff)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68248", "url": "https://ubuntu.com/security/CVE-2026-68248", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915: Return NULL on error in active_instance Avoid returning &node->base when node is NULL due to OOM during GFP_ATOMIC allocation. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 6029bc064f0b1bac184203a50fbaaf070fa18832)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68249", "url": "https://ubuntu.com/security/CVE-2026-68249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma5.0: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit 8d144a0eb09537055841af48c9e7c2d4cd48e84d)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68250", "url": "https://ubuntu.com/security/CVE-2026-68250", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma5.2: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit ae658afc7f47f6147371ec42cc6b1a793dfdb5af)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68251", "url": "https://ubuntu.com/security/CVE-2026-68251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/sdma6.0: replace BUG_ON() with WARN_ON() There's no need to crash the kernel for these cases. (cherry picked from commit c17a508a7d652da3728f8bbc481bfffe96d65a87)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68255", "url": "https://ubuntu.com/security/CVE-2026-68255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/virtio: bound EDID block reads to the response buffer virtio_get_edid_block() validates the read offset only against the device-supplied resp->size field, never against the fixed-size resp->edid array. The EDID block index is driven by the device-supplied extension count, so a malicious virtio-gpu backend can advertise a large size together with a high block count and read far past the array into adjacent kernel memory, which is then surfaced in the parsed EDID (an out-of-bounds read / info leak). Also reject any read whose end exceeds the size of the edid array. Conforming EDID responses stay within the array and are unaffected.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68256", "url": "https://ubuntu.com/security/CVE-2026-68256", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: detect_link_and_local_sink: DP alt mode timeout path leaks prev_sink reference prev_sink is unconditionally retained via dc_sink_retain at function entry, but the DP alt mode timeout path inside SIGNAL_TYPE_DISPLAY_PORT returns false without releasing prev_sink. All other return paths in the function correctly call dc_sink_release(prev_sink), making this the only missing cleanup. (cherry picked from commit 45510cf662dcf46b5d8926d454f338809f107b9d)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68259", "url": "https://ubuntu.com/security/CVE-2026-68259", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Check bounds in allocate_event_notification_slot The valid event ids go from 0 to KFD_SIGNAL_EVENT_LIMIT allocate_event_notification_slot has an option to specify an event id to allocate at, used by CRIU. We weren't checking the bounds on that value. Check them. v2: Lower bounds check is unecessary because of idr_alloc already rejecting negative numbers. Upper bounds check should be KFD_SIGNAL_EVENT_LIMIT since the signal mode mappings might not yet exist (cherry picked from commit 6853f1f6cbbeb3f53ebbbd7286536aeb2c5d5f50)", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68269", "url": "https://ubuntu.com/security/CVE-2026-68269", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/i915/gem: Add missing nospec on parallel submit slot Add missing Spectre mitigation for userspace controlled parallel submission slot. Discovered using AI-assisted static analysis confirmed by Intel Product Security. (cherry picked from commit 15b9353deff3cf72331c387780de3cf9c316b643)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68271", "url": "https://ubuntu.com/security/CVE-2026-68271", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/nouveau: fix reversed error cleanup order in ucopy functions nouveau_uvmm_vm_bind_ucopy() and nouveau_exec_ucopy() place their error cleanup labels in allocation order rather than reverse allocation order. On a u_memcpya() failure for in_sync.s, the goto to err_free_ops (or err_free_pushs) frees the first allocation and then falls through to err_free_ins, which calls u_free() on args->in_sync.s. Since args->in_sync.s still holds the ERR_PTR returned by the failed u_memcpya(), and ERR_PTR values are not caught by ZERO_OR_NULL_PTR(), kvfree() proceeds to dereference it, which can result in a kernel oops. A failure for out_sync.s instead jumps to err_free_ins and skips freeing the first allocation, leading to a memory leak. Fix by swapping the cleanup label order so resources are freed in the correct reverse allocation sequence.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68272", "url": "https://ubuntu.com/security/CVE-2026-68272", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: validate CP_GFX_SHADOW chunk size in CS pass1 Add a minimum-length check for the AMDGPU_CHUNK_ID_CP_GFX_SHADOW chunk in amdgpu_cs_pass1(), matching the gate already present for the IB, FENCE and BO_HANDLES chunk types. The CP_GFX_SHADOW case previously shared a bare break with the dependency and syncobj chunk types, which do not dereference a fixed-size struct. When userspace submits this chunk with length_dw == 0, vmemdup_array_user() is called with size 0 and returns ZERO_SIZE_PTR, which passes the IS_ERR() check. amdgpu_cs_p2_shadow() then dereferences chunk->kdata as a struct drm_amdgpu_cs_chunk_cp_gfx_shadow (reading shadow->flags), faulting on the ZERO_SIZE_PTR and causing a NULL-pointer dereference. This is reachable by an unprivileged process in the render group. Reject undersized chunks with -EINVAL during pass1 so the bad submission is rejected before pass2 ever dereferences the data. (cherry picked from commit 7f61b2eef7415eccdb40850aca0de94211948657)", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68277", "url": "https://ubuntu.com/security/CVE-2026-68277", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/dp/mst: fix OOB reads on 2-byte fields in sideband reply parsers Three sideband reply parsers read 16-bit fields as: val = (raw->msg[idx] << 8) | (raw->msg[idx+1]); and check bounds only after the fact. When idx == raw->curlen, raw->msg[idx+1] reads one byte past the received message data into the following struct fields (curchunk_len, curchunk_idx, curlen). Affected functions: - drm_dp_sideband_parse_enum_path_resources_ack() full_payload_bw_number and avail_payload_bw_number fields - drm_dp_sideband_parse_allocate_payload_ack() allocated_pbn field - drm_dp_sideband_parse_query_payload_ack() allocated_pbn field Fix by using a single combined check (idx + 2 > curlen) before each 2-byte read. Since the check is strictly tighter than idx > curlen, no separate step is needed. [added fixes tag]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68278", "url": "https://ubuntu.com/security/CVE-2026-68278", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/dp/mst: fix buffer overflows in sideband chunk accumulation drm_dp_sideband_append_payload() has three related bugs when processing device-provided sideband reply data: 1. Zero-length curchunk_len underflow: msg_len is a 6-bit field taken directly from the DP sideband header. If a device sends msg_len=0, curchunk_len is set to zero. The condition (curchunk_idx >= curchunk_len) is immediately true, and curchunk_len-1 wraps to 255 (u8 underflow). drm_dp_msg_data_crc4() reads 255 bytes from chunk[48], then memcpy() writes 255 bytes into msg[], both far out of bounds. 2. chunk[48] overflow: curchunk_len can reach 63 (6-bit field). chunk[] is only 48 bytes. Multi-iteration payload assembly appends 16-byte blocks until curchunk_idx reaches curchunk_len, writing up to 15 bytes past the end of chunk[] into msg[]. 3. msg[256] overflow: each chunk contributes (curchunk_len-1) bytes to msg[]. No check ensures curlen + (curchunk_len-1) stays within msg[256], so the memcpy can spill into adjacent struct fields. All three are reachable from any DP MST device that can forge sideband reply messages on a physical connection.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68279", "url": "https://ubuntu.com/security/CVE-2026-68279", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/dp/mst: fix OOB reads in remote DPCD/I2C sideband reply parsers drm_dp_sideband_parse_remote_dpcd_read() reads num_bytes from the raw message and then unconditionally does: memcpy(bytes, &raw->msg[idx], num_bytes); without checking that idx + num_bytes <= raw->curlen. raw->msg[] is 256 bytes; if a malicious or misbehaving MST hub sets num_bytes larger than the remaining payload, the memcpy reads past the received data into whatever follows in raw->msg[]. drm_dp_sideband_parse_remote_i2c_read_ack() has the same flaw (noted with a /* TODO check */ comment since the code was introduced). Fix both functions by using a single combined check (idx + num_bytes > curlen) before each memcpy. Since num_bytes is u8, it is always >= 0, so this strictly subsumes the simpler idx > curlen form and no separate step is needed. [added missing fixes tag]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68280", "url": "https://ubuntu.com/security/CVE-2026-68280", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/bridge: cdns-dsi: Replace deprecated UNIVERSAL_DEV_PM_OPS() The deprecated UNIVERSAL_DEV_PM_OPS() macro uses the provided callbacks for both runtime PM and system sleep. This causes the DSI clocks to be disabled twice: once during runtime suspend and again during system suspend, resulting in a WARN message from the clock framework when attempting to disable already-disabled clocks. [ 84.384540] clk:231:5 already disabled [ 84.388314] WARNING: CPU: 2 PID: 531 at /drivers/clk/clk.c:1181 clk_core_disable+0xa4/0xac ... [ 84.579183] Call trace: [ 84.581624] clk_core_disable+0xa4/0xac [ 84.585457] clk_disable+0x30/0x4c [ 84.588857] cdns_dsi_suspend+0x20/0x58 [cdns_dsi] [ 84.593651] pm_generic_suspend+0x2c/0x44 [ 84.597661] ti_sci_pd_suspend+0xbc/0x15c [ 84.601670] dpm_run_callback+0x8c/0x14c [ 84.605588] __device_suspend+0x1a0/0x56c [ 84.609594] dpm_suspend+0x17c/0x21c [ 84.613165] dpm_suspend_start+0xa0/0xa8 [ 84.617083] suspend_devices_and_enter+0x12c/0x634 [ 84.621872] pm_suspend+0x1fc/0x368 To address this issue, replace UNIVERSAL_DEV_PM_OPS() with RUNTIME_PM_OPS(). Bridge and panel drivers should only deal with runtime PM, as the DRM framework manages system-wide power transitions through the bridge enable() and disable() hooks.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68284", "url": "https://ubuntu.com/security/CVE-2026-68284", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Fix cork use-after-free in tcp_bpf_sendmsg() tcp_bpf_sendmsg() keeps msg_tx across sk_stream_wait_memory(), which drops and reacquires the socket lock. Its error path tries to decide whether msg_tx names the local temporary message by comparing it with the current value of psock->cork. This comparison is unsafe when two threads send on the same socket: Thread A Thread B msg_tx = psock->cork sk_msg_alloc() fails sk_stream_wait_memory() releases the socket lock acquires the socket lock completes the cork psock->cork = NULL frees the cork reacquires the socket lock msg_tx != psock->cork sk_msg_free(msg_tx) The stale cork is therefore mistaken for the local temporary message and freed again. KASAN reported: BUG: KASAN: slab-use-after-free in sk_msg_free+0x49/0x50 Read of size 4 at addr ffff88810c908800 by task poc/90 Call Trace: sk_msg_free+0x49/0x50 tcp_bpf_sendmsg+0x14f5/0x1cc0 __sys_sendto+0x32c/0x3a0 __x64_sys_sendto+0xdb/0x1b0 Allocated by task 89: __kasan_kmalloc+0x8f/0xa0 tcp_bpf_sendmsg+0x16b3/0x1cc0 Freed by task 91: __kasan_slab_free+0x43/0x70 kfree+0x131/0x3c0 tcp_bpf_sendmsg+0xec3/0x1cc0 msg_tx can only name the stack-local tmp or the shared cork. Check for tmp directly so a changed psock->cork cannot turn a shared message into an apparent local one.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68294", "url": "https://ubuntu.com/security/CVE-2026-68294", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qrtr: restrict socket creation to the initial network namespace QRTR keeps its entire port and node state in module-global variables that are not partitioned per network namespace: qrtr_local_nid is a single global node id (always 1) and qrtr_ports is a single global xarray. qrtr_port_lookup() and qrtr_local_enqueue() operate on that global state with no network-namespace check, and qrtr_create() places no restriction on the namespace a socket is created in. As a result an unprivileged process that creates an AF_QIPCRTR socket in a separate network namespace, e.g. via unshare(CLONE_NEWUSER | CLONE_NEWNET), can send QRTR datagrams - including control-plane messages such as QRTR_TYPE_NEW_SERVER - to QRTR sockets owned by another namespace, and vice versa. The receiving socket sees such a message as coming from node id 1, indistinguishable from a legitimate local client, breaking the isolation that network namespaces are expected to provide. QRTR is a transport to global hardware endpoints (the modem and other remote processors) and has no per-namespace semantics; its in-kernel name service already creates its socket in init_net only. Confine the socket family to the initial network namespace, as other non-namespace-aware socket families do (see llc_ui_create() and the ieee802154 socket code).", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68297", "url": "https://ubuntu.com/security/CVE-2026-68297", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix u16 MTU truncation in media and bearer MTU validation Both TIPC_NL_MEDIA_SET and TIPC_NL_BEARER_SET accept user-supplied MTU values but only enforce a minimum bound, not a maximum. When a user sets the MTU to a value exceeding U16_MAX (65535), it passes validation but is silently truncated when assigned to u16 fields l->mtu and l->advertised_mtu in tipc_link_create(). Values like 65536 (0x10000) truncate to 0, causing a division by zero in tipc_link_set_queue_limits() which computes TIPC_MAX_PUBL / (l->mtu / ITEM_SIZE). Other overflowing values (e.g. 65537-131071) produce small incorrect MTU values, resulting in link malfunction behaviors. Crash stack (triggered as unprivileged user via user namespace): tipc_link_set_queue_limits net/tipc/link.c:2531 tipc_link_create net/tipc/link.c:520 tipc_node_check_dest net/tipc/node.c:1279 tipc_disc_rcv net/tipc/discover.c:252 tipc_rcv net/tipc/node.c:2129 tipc_udp_recv net/tipc/udp_media.c:392 Two independent paths lack the upper bound check: 1. tipc_udp_mtu_bad() -- called from __tipc_nl_media_set() (MEDIA_SET) 2. inline check in __tipc_nl_bearer_set() at bearer.c:1160 (BEARER_SET) Fix both by rejecting MTU values above U16_MAX.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68299", "url": "https://ubuntu.com/security/CVE-2026-68299", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vmxnet3: fix BUG_ON in vmxnet3_get_hdr_len() for Geneve packets vmxnet3_get_hdr_len() assumes gdesc->rcd.v4/v6/tcp always describe the outer header, but for a Geneve-encapsulated packet the device can set them based on the inner header instead, signalled by the VMXNET3_RCD_HDR_INNER_SHIFT bit in the completion descriptor. Since the function never skips the outer encapsulation, this mismatch triggers: - BUG_ON(hdr.ipv4->protocol != IPPROTO_TCP), because the outer protocol is UDP (Geneve), not TCP. - BUG_ON(hdr.eth->h_proto != ...), when the tunnel's outer and inner IP versions differ (e.g. outer IPv6/inner IPv4 or vice versa). Check VMXNET3_RCD_HDR_INNER_SHIFT up front and bail out, since the function cannot locate the inner header it would need to parse. Also convert the remaining BUG_ON()s in this function to return 0 defensively.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68300", "url": "https://ubuntu.com/security/CVE-2026-68300", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: auth: verify auth requirement when auth_chunk is NULL sctp_auth_chunk_verify() returns true unconditionally when chunk->auth_chunk is NULL, silently skipping authentication. This is incorrect when: 1. skb_clone() failed in the BH receive path, leaving auth_chunk NULL. In sctp_endpoint_bh_rcv() asoc is NULL for new connections, so the early sctp_auth_recv_cid() check cannot catch this. 2. No AUTH chunk precedes COOKIE-ECHO, so skb_clone() is never called and auth_chunk remains NULL. Fix by checking sctp_auth_recv_cid() when auth_chunk is NULL: if authentication is required, return false to drop the chunk; otherwise continue normally.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68301", "url": "https://ubuntu.com/security/CVE-2026-68301", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hsr: fix memory leak on slave unregistration by removing synced VLANs When an HSR master device is brought UP, it auto-adds VLAN 0 via vlan_vid0_add(), which propagates VID 0 to its slave devices (slave A and B). If a slave device is later unregistered while HSR is active (e.g., during netns cleanup or interface destruction), hsr_del_port() is called to detach the slave port from the HSR master. However, hsr_del_port() currently does not delete the VLAN IDs that were synced to the slave device by HSR. As a result, the slave device retains a refcount on VID 0 (and any other synced VLANs). When the slave device is destroyed, its vlan_info / vlan_vid_info structure remains allocated, leading to a memory leak. Fix this by calling vlan_vids_del_by_dev(port->dev, master->dev) in hsr_del_port() before unlinking slave A or slave B ports, matching the propagation logic in hsr_ndo_vlan_rx_add_vid() / hsr_ndo_vlan_rx_kill_vid() and the cleanup behavior in bonding and team drivers.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68302", "url": "https://ubuntu.com/security/CVE-2026-68302", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: amt: re-read skb header pointers after every pull Several AMT receive and transmit paths cache a pointer into the skb head (ip_hdr(), ipv6_hdr(), eth_hdr() or the AMT message header) and then call a helper that can reallocate that head before the cached pointer is used again. pskb_may_pull(), ip_mc_may_pull(), ipv6_mc_may_pull(), iptunnel_pull_header(), ip_mc_check_igmp() and ipv6_mc_check_mld() can all free the old head and move the data, so a pointer taken before the call dangles afterwards and the later access is a use-after-free of the freed head. The affected sites are: amt_rcv() caches ip_hdr() before amt_parse_type() pulls, then reads iph->saddr. amt_dev_xmit() caches ip_hdr()/ipv6_hdr() before ip_mc_check_igmp()/ ipv6_mc_check_mld() and pskb_may_pull(), then reads the group address. amt_multicast_data_handler() caches eth_hdr() before pskb_may_pull(), then writes the L2 header. amt_membership_query_handler() caches the AMT header, the outer and inner eth_hdr() and ip_hdr() before iptunnel_pull_header() and several pulls, then reads and writes them. amt_igmpv3_report_handler() and amt_mldv2_report_handler() cache ip_hdr()/ipv6_hdr() and the current group record and read the record count from the report header inside the record loop, across the *_mc_may_pull() calls. amt_update_handler() caches ip_hdr() and the AMT membership-update header before pskb_may_pull(), iptunnel_pull_header(), ip_mc_check_igmp() and the report handler, then reads iph->daddr and amtmu->nonce / amtmu->response_mac. Fix each site by either snapshotting the scalar that is used after the pull before the first pull runs, or re-deriving the header pointer from the skb after the last pull that can move the head. Values that are stable across the pull (source and group address, the response MAC and nonce, the record count, the outer source MAC) are snapshotted; pointers that are written through or read repeatedly are re-derived.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68304", "url": "https://ubuntu.com/security/CVE-2026-68304", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: fix 802.1X-SHA256 call trace warning Based on wpa_auth as 1x_256 mode, need to set up \"use_fwsup\" with BRCMF_PROFILE_FWSUP_1X. Or it will happen trace warning when call brcmf_cfg80211_set_pmk(). [ 4481.831101] ------------[ cut here ]------------ [ 4481.831102] WARNING: CPU: 1 PID: 2997 at drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c:7242 brcmf_cfg80211_set_pmk+0x77/0xd0 [brcmfmac] [...] [ 4481.831202] Call Trace: [ 4481.831204]   [ 4481.831205]  nl80211_set_pmk+0x183/0x250 [cfg80211] [ 4481.831233]  genl_family_rcv_msg_doit+0xea/0x150 [ 4481.831237]  genl_rcv_msg+0x104/0x240 [ 4481.831239]  ? cfg80211_probe_status+0x2c0/0x2c0 [cfg80211] [ 4481.831257]  ? genl_family_rcv_msg_doit+0x150/0x150 [ 4481.831259]  netlink_rcv_skb+0x4e/0x100 [ 4481.831261]  genl_rcv+0x24/0x40 [ 4481.831262]  netlink_unicast+0x236/0x380 [ 4481.831264]  netlink_sendmsg+0x250/0x4b0 [ 4481.831266]  sock_sendmsg+0x5c/0x70 [ 4481.831269]  ____sys_sendmsg+0x236/0x2b0 [ 4481.831271]  ? copy_msghdr_from_user+0x6d/0xa0 [ 4481.831272]  ___sys_sendmsg+0x86/0xd0 [ 4481.831274]  ? avc_has_perm+0x8c/0x1a0 [ 4481.831276]  ? preempt_count_add+0x6a/0xa0 [ 4481.831279]  ? sock_has_perm+0x82/0xa0 [ 4481.831280]  __sys_sendmsg+0x57/0xa0 [ 4481.831282]  do_syscall_64+0x38/0x90 [ 4481.831284]  entry_SYSCALL_64_after_hwframe+0x63/0xcd [ 4481.831286] RIP: 0033:0x7fd270d369b4", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68306", "url": "https://ubuntu.com/security/CVE-2026-68306", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: fix possible NULL-pointer deref in mt7996_mcu_sta_bfer_eht() mt76_connac_get_eht_phy_cap routine can theoretically return NULL so check cap pointer before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68308", "url": "https://ubuntu.com/security/CVE-2026-68308", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: check pointer returned by mt76_connac_get_he_phy_cap() mt76_connac_get_he_phy_cap routine can theoretically return NULL so check cap pointer before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68309", "url": "https://ubuntu.com/security/CVE-2026-68309", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: connac: fix possible NULL-pointer deref in mt76_connac_mcu_uni_bss_he_tlv() mt76_connac_get_he_phy_cap routine can theoretically return NULL so check cap pointer before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68310", "url": "https://ubuntu.com/security/CVE-2026-68310", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7915: guard HE capability lookups mt7915_mcu_bss_he_tlv() and mt7915_mcu_sta_bfer_tlv() both run after checking HE support, then dereference the HE PHY capability returned by mt76_connac_get_he_phy_cap(). That helper can return NULL when no capability entry matches the vif type. Fetch the capability before appending the TLV and skip the HE-specific setup when no matching capability is available.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68313", "url": "https://ubuntu.com/security/CVE-2026-68313", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix infinite loop in __tipc_nl_compat_dumpit cmd->dumpit callback can return a negative errno, causing an infinite loop due to the while(len) condition. As the loop never terminates, genl_mutex is never released, and other tasks waiting on it starve in D state. Check dumpit's return value, propagate it and jump to err_out on error.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64576", "url": "https://ubuntu.com/security/CVE-2026-64576", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nexthop: initialize extack in nh_res_bucket_migrate() nh_res_bucket_migrate() passes an uninitialized netlink_ext_ack to call_nexthop_res_bucket_notifiers(). When nh_notifier_res_bucket_info_init() fails (e.g. the kzalloc returns -ENOMEM), the error is propagated back before any notifier sets extack._msg, and the error path formats the stale pointer with pr_err_ratelimited(\"%s\\n\", extack._msg). With CONFIG_INIT_STACK_NONE this dereferences uninitialized stack memory: Oops: general protection fault, probably for non-canonical address ... KASAN: maybe wild-memory-access in range [...] RIP: 0010:string (lib/vsprintf.c:730) vsnprintf (lib/vsprintf.c:2945) _printk (kernel/printk/printk.c:2504) nh_res_bucket_migrate (net/ipv4/nexthop.c:1816) nh_res_table_upkeep (net/ipv4/nexthop.c:1866) rtm_new_nexthop (net/ipv4/nexthop.c:3323) rtnetlink_rcv_msg (net/core/rtnetlink.c:7076) netlink_sendmsg (net/netlink/af_netlink.c:1900) Kernel panic - not syncing: Fatal exception Zero-initialize extack so _msg is NULL on error paths that never set it.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-64577", "url": "https://ubuntu.com/security/CVE-2026-64577", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gtp: check skb_pull_data() return in gtp1u_send_echo_resp() gtp1u_send_echo_resp() ignores skb_pull_data()'s return value. Its caller gtp1u_udp_encap_recv() only guarantees 16 bytes (udphdr + gtp1_header), but the pull requests 20 (gtp1_header_long + udphdr). For a 16-19 byte echo request the pull fails and returns NULL without advancing skb->data; execution continues, and the following skb_push() plus the IP header pushed by iptunnel_xmit() move skb->data below skb->head, tripping skb_under_panic(). Fix it by dropping the packet when skb_pull_data() fails. skbuff: skb_under_panic: ... kernel BUG at net/core/skbuff.c:214! Call Trace: skb_push (net/core/skbuff.c:2648) iptunnel_xmit (net/ipv4/ip_tunnel_core.c:82) gtp_encap_recv (drivers/net/gtp.c:701 drivers/net/gtp.c:808 drivers/net/gtp.c:920) udp_queue_rcv_one_skb (net/ipv4/udp.c:2388) ... Kernel panic - not syncing: Fatal exception in interrupt", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68315", "url": "https://ubuntu.com/security/CVE-2026-68315", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: validate stream count in sctp_process_strreset_inreq() When processing a RESET_IN_REQUEST from a peer, sctp_process_strreset_inreq() derives the stream count from the parameter length but does not check whether the resulting RESET_OUT_REQUEST would exceed SCTP_MAX_CHUNK_LEN. The OUT request header (sctp_strreset_outreq, 16 bytes) is 8 bytes larger than the IN request header (sctp_strreset_inreq, 8 bytes). Generally, the IP payload is bounded to 65535 bytes, so the stream list cannot be large enough to trigger the overflow. However, on interfaces with MTU > 65535 (e.g., loopback with IPv6 jumbograms), a stream list that fits within the incoming IN parameter can cause a __u16 overflow in sctp_make_strreset_req() when computing the OUT request size, leading to an undersized skb allocation and a kernel BUG: net/core/skbuff.c:207 skb_panic net/core/skbuff.c:2625 skb_put net/sctp/sm_make_chunk.c:1535 sctp_addto_chunk net/sctp/sm_make_chunk.c:3695 sctp_make_strreset_req net/sctp/stream.c:655 sctp_process_strreset_inreq The local setsockopt path validates the generated reset request size. However, for an incoming-only reset, it accounts for the smaller IN request even though the peer must generate an OUT request with the same stream list. Such a request cannot be completed successfully by the peer. Reject peer IN requests whose corresponding OUT request would exceed SCTP_MAX_CHUNK_LEN. Also tighten the local check so it does not send an IN request that would require an oversized OUT request from the peer.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68317", "url": "https://ubuntu.com/security/CVE-2026-68317", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pds_core: fix auxiliary device add/del races Two paths add or delete the same slot (pf->vfs[vf_id].padev): a VF's pdsc_reset_done() and the PF's devlink enable_vnet/disable_vnet handler. They serialize on config_lock, but neither guards the slot under it correctly. add() registers and stores a new auxiliary device without first checking the slot, so a second add of an already-populated slot leaks the first device. del() makes that check outside config_lock, so two concurrent dels can both pass it; the first clears the slot, and the second dereferences a NULL pointer. Check and update the slot under config_lock in both paths.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68320", "url": "https://ubuntu.com/security/CVE-2026-68320", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: fix auth_chunk_list capacity check in sctp_auth_ep_add_chunkid sctp_auth_ep_add_chunkid() uses SCTP_NUM_CHUNK_TYPES (20) as the capacity limit for ep->auth_chunk_list, allowing it to hold up to 20 chunk entries (param_hdr.length up to 24). However, the copy destination asoc->c.auth_chunks in struct sctp_cookie is only SCTP_AUTH_MAX_CHUNKS (16) entries (20 bytes). When more than 16 chunks are added, sctp_association_init() memcpy overflows the destination by up to 4 bytes. Fix by using SCTP_AUTH_MAX_CHUNKS as the capacity limit, matching the destination capacity.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68324", "url": "https://ubuntu.com/security/CVE-2026-68324", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/intel: Fix out-of-bounds memset in dmar_latency_disable() dmar_latency_disable() intends to zero out only the single latency_statistic entry for the given type, but the memset size was computed as sizeof(*lstat) * DMAR_LATENCY_NUM, which clears the entire array starting from &lstat[type]. When type > 0, this writes beyond the end of the allocated array, corrupting adjacent memory. Fix by using sizeof(*lstat) to clear only the target entry.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68325", "url": "https://ubuntu.com/security/CVE-2026-68325", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Bound the early ACPI HID map The ivrs_acpihid command-line parser appends entries to a fixed four-element early_acpihid_map array. Unlike the sibling IOAPIC and HPET parsers, it does not reject a fifth entry before incrementing the map size. Check the capacity at the common found label before parsing the HID and UID or writing the entry.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68326", "url": "https://ubuntu.com/security/CVE-2026-68326", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: bound uAP association event IEs to the event buffer mwifiex_process_uap_event() handles EVENT_UAP_STA_ASSOC by exposing the (re)association request IEs that the firmware copies into the event: \tsinfo->assoc_req_ies = &event->data[len]; \tlen = (u8 *)sinfo->assoc_req_ies - (u8 *)&event->frame_control; \tsinfo->assoc_req_ies_len = le16_to_cpu(event->len) - (u16)len; event->len is supplied by the device firmware and is never validated, and the subtraction is unchecked. assoc_req_ies points into adapter->event_body[MAX_EVENT_SIZE], a fixed-size array embedded in the kmalloc()'d struct mwifiex_adapter. On the ap_11n_enabled path mwifiex_set_sta_ht_cap() walks these IEs with cfg80211_find_ie(), whose for_each_element() loop dereferences each element header. A firmware-reported event->len larger than the bytes actually received makes assoc_req_ies_len describe IEs that extend past event_body, so the walk reads out of the adapter slab object, a slab-out-of-bounds read (KASAN: slab-out-of-bounds in cfg80211_find_ie). An event->len smaller than the header instead makes the int subtraction negative, which wraps to a huge size_t when stored in assoc_req_ies_len. The same length is handed to cfg80211_new_sta(), so a more modest over-claim can also copy stale event_body bytes into the NL80211_CMD_NEW_STATION notification. A malicious or malfunctioning mwifiex device (USB/SDIO/PCIe) can deliver such an event while the interface is in AP/uAP mode. Validate event->len before use: reject a length that underflows the header or that would place the IEs outside the event_body[] buffer the event was copied into. event->len here is struct mwifiex_assoc_event.len, a payload field internal to this event, not the transport frame length, so it is validated in this handler rather than at the generic MWIFIEX_TYPE_EVENT receive path, which only sees the event cause and the transport frame length. The bound is against event_body[MAX_EVENT_SIZE] rather than the actually-received length because the transports store the event differently (USB and SDIO leave the 4-byte event header in event_skb, PCIe strips it via skb_pull), whereas event_body is the single fixed buffer all of them copy the event into. This is the event-path analogue of the receive-path bounds checks added in commit 119585281617 (\"wifi: mwifiex: Fix OOB and integer underflow when rx packets\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68327", "url": "https://ubuntu.com/security/CVE-2026-68327", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wan: wanxl: Only reset hardware after BAR mapping wanxl_pci_init_one() stores the freshly allocated card in driver data before the PLX BAR is mapped. Several early probe failures then unwind through wanxl_pci_remove_one(), including failure to allocate the coherent status area or to restore the DMA mask. wanxl_pci_remove_one() unconditionally calls wanxl_reset(), and wanxl_reset() dereferences card->plx. On those early failures card->plx is still NULL, so the error path can dereference a NULL MMIO pointer. Only issue the hardware reset once the BAR mapping exists. The remaining cleanup in wanxl_pci_remove_one() already checks whether later resources were allocated. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68328", "url": "https://ubuntu.com/security/CVE-2026-68328", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfp: Check resource mutex allocation nfp_cpp_resource_find() allocates a CPP mutex handle for the matching resource-table entry and then reports success. nfp_resource_try_acquire() immediately passes that handle to nfp_cpp_mutex_trylock(). However, nfp_cpp_mutex_alloc() returns NULL on failure. If that happens for a matching table entry, the resource lookup still returns success and the following trylock dereferences a NULL mutex pointer while opening the resource. nfp_resource_acquire() already treats failure to allocate the table mutex as -ENOMEM. Do the same for the resource mutex and fail the lookup before publishing the rest of the resource handle. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64574", "url": "https://ubuntu.com/security/CVE-2026-64574", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: tear down new links on vif update error path When ieee80211_vif_update_links() adds new links it allocates a link container for each and calls ieee80211_link_init() (which registers the per-link debugfs files with file->private_data pointing into the container) and ieee80211_link_setup(). If the subsequent drv_change_vif_links() fails, the error path restores the old pointers and jumps to 'free', which frees the new containers but never removes their debugfs entries or stops the links. The debugfs files survive with file->private_data dangling at the freed container, so a later open()+read() (e.g. link-1/txpower) dereferences freed memory in ieee80211_if_read_link(), a use-after-free. The removal path already dismantles links correctly via ieee80211_tear_down_links(), which removes each link's keys and debugfs entries and calls ieee80211_link_stop(); the add path on the error branch does not. Commit be1ba9ed221f (\"wifi: mac80211: avoid weird state in error path\") hardened this same error path for the link-removal case (new_links == 0) but left the newly-added links' teardown unaddressed. drv_change_vif_links() can fail at runtime on MLO drivers (internal allocation / queue / firmware command failures). Remove the new links' debugfs entries and stop them before freeing. BUG: KASAN: slab-use-after-free in ieee80211_if_read_link (net/mac80211/debugfs_netdev.c:127) Read of size 8 at addr ffff888011290000 by task exploit/145 Call Trace: ... ieee80211_if_read_link (net/mac80211/debugfs_netdev.c:127) short_proxy_read (fs/debugfs/file.c:373) vfs_read (fs/read_write.c:572) ksys_read (fs/read_write.c:716) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) ... Oops: general protection fault, probably for non-canonical address 0xdffffc000000000a RIP: 0010:ieee80211_if_read_link (net/mac80211/debugfs_netdev.c:127) Kernel panic - not syncing: Fatal exception", "cve_priority": "low", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68329", "url": "https://ubuntu.com/security/CVE-2026-68329", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Wait for completion instead of returning early in iommu_completion_wait() need_sync is a per-IOMMU flag shared by all domains and devices behind that IOMMU. It is set whenever a command is queued with sync == true and cleared when a completion-wait (CWAIT) command is queued. However, a cleared need_sync only means that a covering CWAIT has been queued, not that all previously queued commands have actually completed in hardware. iommu_completion_wait() read need_sync locklessly and returned early when it was false. This breaks the \"block until all previously queued commands have completed\" contract in a multi-CPU scenario: CPU2: queue inv-B => need_sync = true CPU1: queue CWAIT(N); need_sync = false; then wait_on_sem(N) CPU2: read need_sync == false => return 0 (no wait!) CPU2 returns without waiting for any sequence number even though its inv-B may not have completed yet (CWAIT(N), queued after inv-B, has not been signaled). CPU2 then proceeds to, for example, free page-table pages while the IOMMU can still walk stale translations, opening a use-after-free window. This is a logical race in the meaning of the flag, not a memory-visibility issue, so barriers alone do not help. Fix it without losing the optimization of avoiding redundant CWAIT commands: take iommu->lock before testing need_sync, and when it is false do not return early but wait for the last allocated sequence number (cmd_sem_val). Since need_sync == false implies no sync command was queued after the last CWAIT, that CWAIT is FIFO-ordered after every not-yet-completed command, so waiting for its sequence number guarantees all prior commands (possibly queued by another CPU) have completed. The common path with pending work is unchanged and no extra hardware command is issued.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68331", "url": "https://ubuntu.com/security/CVE-2026-68331", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dpaa2-eth: put MAC endpoint device on disconnect fsl_mc_get_endpoint() returns the MAC endpoint device with a reference taken through device_find_child(). The Ethernet connect path stores that device in mac->mc_dev and keeps it for the lifetime of the connected MAC object. However, the disconnect path only disconnects and closes the MAC before freeing the dpaa2_mac object. It does not drop the endpoint device reference stored in mac->mc_dev, so every successful connect leaks that device reference when the MAC is later disconnected. Drop the endpoint device reference after closing the MAC and before freeing the dpaa2_mac object.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68333", "url": "https://ubuntu.com/security/CVE-2026-68333", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dpaa2-switch: put MAC endpoint device on disconnect fsl_mc_get_endpoint() returns the MAC endpoint device with a reference taken through device_find_child(). The switch port connect path stores that device in mac->mc_dev and keeps it for the lifetime of the connected MAC object. However, the disconnect path only closes the MAC and frees the dpaa2_mac object. It does not drop the endpoint device reference stored in mac->mc_dev, so every successful connect leaks that device reference when the MAC is later disconnected. Drop the endpoint device reference before freeing the dpaa2_mac object.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68335", "url": "https://ubuntu.com/security/CVE-2026-68335", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rds: drop incoming messages that cross network namespace boundaries rds_find_bound() looks up the destination socket using a global rhashtable keyed solely on (addr, port, scope_id). Network namespaces are not part of the key, so a sender in netns A can deliver an incoming message (inc) to a socket that lives in a different netns B. When this happens, inc->i_conn points to an rds_connection whose c_net is netns A, but the receiving rs lives in netns B. Once the child process that created netns A exits, cleanup_net() calls rds_loop_exit_net() -> rds_loop_kill_conns() -> rds_conn_destroy(), freeing that connection. If the survivor socket in netns B still holds the inc, any subsequent dereference of inc->i_conn is a use-after-free. There are two dangerous sites in rds_clear_recv_queue(): 1. inc->i_conn->c_lcong (offset 88 of freed rds_connection, size 200) read via rds_recv_rcvbuf_delta() -- confirmed by KASAN. 2. inc->i_conn->c_trans->inc_free(inc) (function pointer at offset 80) called via rds_inc_put() when the inc refcount reaches zero -- same race window, potential call-through-freed-object primitive. The bug is reachable from unprivileged user namespaces (CLONE_NEWUSER + CLONE_NEWNET), available since Linux 3.8. Fix this by rejecting the delivery in rds_recv_incoming() when the socket returned by rds_find_bound() belongs to a different network namespace than the connection that carried the message. Use the existing rds_conn_net() / sock_net() helpers and net_eq() for the comparison.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68336", "url": "https://ubuntu.com/security/CVE-2026-68336", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bonding: fix devconf_all NULL dereference when IPv6 is disabled When booting with the 'ipv6.disable=1' parameter, the devconf_all is never initialized because inet6_init() exits before addrconf_init() is called which initializes it. bond_send_validate(), however, will still call bond_ns_send_all() even ipv6 is indeed disabled. It will lead to NULL derefence of net->ipv6.devconf_all in ip6_pol_route(). BUG: kernel NULL pointer dereference, address: 000000000000000c [...] Workqueue: bond0 bond_arp_monitor [bonding] RIP: 0010:ip6_pol_route+0x69/0x480 [...] Call Trace: ? srso_return_thunk+0x5/0x5f ? __pfx_ip6_pol_route_output+0x10/0x10 fib6_rule_lookup+0xfe/0x260 ? wakeup_preempt+0x8a/0x90 ? srso_return_thunk+0x5/0x5f ? srso_return_thunk+0x5/0x5f ? sched_balance_rq+0x369/0x810 ip6_route_output_flags+0xd7/0x170 bond_ns_send_all+0xde/0x280 [bonding] bond_ab_arp_probe+0x296/0x320 [bonding] ? srso_return_thunk+0x5/0x5f bond_activebackup_arp_mon+0xb4/0x2c0 [bonding] process_one_work+0x196/0x370 worker_thread+0x1af/0x320 ? srso_return_thunk+0x5/0x5f ? __pfx_worker_thread+0x10/0x10 kthread+0xe3/0x120 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x199/0x260 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Fix this by adding ipv6_mod_enabled() condition check in the caller.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68338", "url": "https://ubuntu.com/security/CVE-2026-68338", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/packet: avoid fanout hook re-registration after unregister packet_set_ring() temporarily detaches a socket from packet delivery while reconfiguring its ring. It records the previous running state, clears po->num, unregisters the protocol hook when needed, drops po->bind_lock, and later restores po->num and re-registers the hook from the saved was_running value. That unlocked window can race with NETDEV_UNREGISTER. The notifier can observe the socket as not running, skip __unregister_prot_hook(), and invalidate the per-socket binding by setting po->ifindex to -1 and clearing po->prot_hook.dev. A one-member fanout group can still retain its shared fanout hook device pointer. When packet_set_ring() resumes, re-registering solely from the stale was_running state can re-add the fanout hook after the device has been unregistered. Treat po->ifindex == -1 as an invalidated binding after reacquiring po->bind_lock. This is distinct from ifindex 0, the normal unbound/wildcard state: ifindex -1 marks an existing device binding that was invalidated when the device was unregistered. Restore po->num as before, but do not re-register the hook if device unregister already detached the socket.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68339", "url": "https://ubuntu.com/security/CVE-2026-68339", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: validate Realtek vendor event length btusb_recv_event_realtek() reads the event code at data[0] and the Realtek subevent code at data[2] before deciding whether to consume a vendor event as a coredump. For example, the two-byte event ff 00 contains a complete vendor-event header declaring zero parameters. The old classifier still reads a nonexistent third byte and can misclassify the event as a coredump if the adjacent byte is 0x34. Require the HCI event header and first parameter to be present before inspecting the Realtek subevent code. Short events continue through the normal HCI receive path, which owns their protocol validation.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68340", "url": "https://ubuntu.com/security/CVE-2026-68340", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: occ: validate poll response sensor blocks The OCC poll response parser walks a counted list of sensor data blocks. It used the static backing-array capacity as the parse boundary, but a transport response makes only data_length bytes current and valid. A truncated response can therefore make the parser consume a block header or block extent outside the current response. Use data_length as the parent boundary, prove the fixed poll header and each current block header before reading them, and prove the complete block before advancing. Keep parsed sensor metadata local until the complete response has passed validation, then publish it. Propagate malformed-response errors before publishing the OCC as active.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68343", "url": "https://ubuntu.com/security/CVE-2026-68343", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: validate DFS referral PathConsumed parse_dfs_referrals() validates that the response contains the fixed referral entry array and, on for-next, the per-referral string offsets. However, the response also contains a PathConsumed value that is later used for DFS path parsing. If a malformed response provides a PathConsumed value larger than the search name, later DFS parsing can advance beyond the end of the path. Validate PathConsumed against the search name length before storing it in the parsed referral.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68348", "url": "https://ubuntu.com/security/CVE-2026-68348", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: tas2781: bound firmware description string parsing The TAS2781 firmware parser reads several variable-length description strings with strlen() before checking that the string terminator is present inside the firmware blob. A malformed firmware image without a NUL terminator can therefore make the parser walk past the end of the firmware buffer before the later size checks run. Add a small bounded string-length helper and use it for all description fields that are parsed from the firmware buffer. Keep the existing size checks for the fixed bytes that follow each string.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68450", "url": "https://ubuntu.com/security/CVE-2026-68450", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: free mapping node on duplicate reloc root insert __add_reloc_root() allocates a mapping_node before inserting it into rc->reloc_root_tree. If rb_simple_insert() finds an existing entry, it returns the existing rb_node and leaves the newly allocated node unlinked. The error path then returns -EEXIST without freeing the new node. Since the node was never inserted into reloc_root_tree, the later cleanup in put_reloc_control() cannot find it either. Free the newly allocated node before returning -EEXIST. The callers currently assert that -EEXIST should not happen, so this is a defensive cleanup for an unexpected duplicate insert path. If the path is ever reached, the local allocation should still be released.", "cve_priority": "medium", "cve_public_date": "2026-08-12 01:17:00 UTC" }, { "cve": "CVE-2026-68349", "url": "https://ubuntu.com/security/CVE-2026-68349", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: carl9170: fix buffer overflow in rx_stream failover path The failover continuation in carl9170_rx_stream() copies the full tlen from the second USB transfer instead of capping at rx_failover_missing bytes. When both transfers are near maximum size, the total exceeds the 65535-byte failover SKB, triggering skb_over_panic. Limit the copy size to the missing byte count. [Fix checkpatch CHECK:PARENTHESIS_ALIGNMENT]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68350", "url": "https://ubuntu.com/security/CVE-2026-68350", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: carl9170: fix OOB read from off-by-two in TX status handler The bounds check in carl9170_tx_process_status() uses `i > ((cmd->hdr.len / 2) + 1)` which is off by two, allowing 2 extra iterations past valid _tx_status entries when the firmware- controlled hdr.ext exceeds hdr.len/2. Fix by using the correct comparison `i >= (cmd->hdr.len / 2)`.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68351", "url": "https://ubuntu.com/security/CVE-2026-68351", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: carl9170: bound memcpy length in cmd callback to prevent OOB read When the firmware sends a command response with a length mismatch, carl9170_cmd_callback() logs the mismatch and calls carl9170_restart() but then falls through to memcpy(ar->readbuf, buffer + 4, len - 4). Since len comes from the firmware and can exceed ar->readlen, this copies more data than the readbuf was allocated for. Bound the memcpy to min(len - 4, ar->readlen) so that the response is still completed -- avoiding repeated restarts from queued garbage -- while preventing an overread past the response buffer.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68352", "url": "https://ubuntu.com/security/CVE-2026-68352", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: fix OOB read from firmware IE lengths in connect event The firmware-controlled beacon_ie_len, assoc_req_len, and assoc_resp_len fields in ath6kl_wmi_connect_event_rx() are not validated against the buffer length. Their sum (up to 765) can exceed the actual WMI event data, causing out-of-bounds reads during IE parsing and state corruption of wmi->is_wmm_enabled. Add a check that the total IE length fits within the buffer.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68353", "url": "https://ubuntu.com/security/CVE-2026-68353", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: fix OOB read from firmware num_msg in TX complete handler The firmware-controlled num_msg field (u8, 0-255) drives the loop in ath6kl_wmi_tx_complete_event_rx() without validation against the buffer length. This allows out-of-bounds reads of up to 1020 bytes past the WMI event buffer when the firmware sends an inflated num_msg. Add a check that the buffer is large enough to hold the fixed struct and the num_msg variable-length entries.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68354", "url": "https://ubuntu.com/security/CVE-2026-68354", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firewire: net: Fix fragmented datagram reassembly fwnet_frag_new() keeps a sorted list of received fragments for a partial datagram. When a new fragment is adjacent to an existing fragment, the code checks whether the new fragment also closes the gap to the next or previous list entry. Those neighbor lookups currently assume that the current fragment always has a real next or previous fragment. At a list edge, the next or previous entry is the list head, not a struct fwnet_fragment_info. The gap checks also compare against the old edge of the current fragment instead of the edge after adding the new fragment. As a result, a fragment that bridges two existing ranges may leave two adjacent ranges unmerged, so fwnet_pd_is_complete() can miss a complete datagram. Check for the list head before looking up the neighboring fragment, and compare the neighbor against the new fragment's far edge when deciding whether to merge all three ranges. This issue was found by a static analysis checker and confirmed by manual source review.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68355", "url": "https://ubuntu.com/security/CVE-2026-68355", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix potential buffer underflow in ath11k_hal_rx_msdu_list_get() When the first entry in msdu_details has a zero buffer address, the code accesses msdu_details[i - 1] with i == 0, causing a buffer underflow. Fix similarly to ath12k_wifi7_hal_rx_msdu_list_get() by adding a separate check for i == 0 before the main condition to prevent the out-of-bounds access. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68357", "url": "https://ubuntu.com/security/CVE-2026-68357", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: watchdog: pretimeout: Fix UAF in watchdog_unregister_governor() When a watchdog governor is unregistered, it updates existing watchdog devices that were using this governor by falling back to `default_gov`. If the governor being unregistered is currently set as `default_gov`, the `default_gov` is never cleared. This leads to 2 use-after-free issues: 1. New watchdog devices registered after this point will inherit the dangling `default_gov`. 2. Existing watchdog devices using the unregistered governor will have their `wdd->gov` reassigned to the dangling `default_gov`. Fix the UAF by clearing `default_gov` if it matches the governor being unregistered.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68359", "url": "https://ubuntu.com/security/CVE-2026-68359", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (nzxt-smart2) Stop device IO before calling hid_hw_stop Calling hid_hw_stop() does not stop the device IO. This results in a race condition between hid_input_report() and the point immediately following the execution of hid_device_io_start() within the driver probe function. If the probe operation fails after \"io start\" has been initiated, this race condition will result in a UAF vulnerability. Fix the problem by calling hid_device_io_stop() before calling hid_hw_stop().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68360", "url": "https://ubuntu.com/security/CVE-2026-68360", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (corsair-cpro) Stop device IO before calling hid_hw_stop Calling hid_hw_stop() does not stop the device IO. This results in a race condition between hid_input_report() and the point immediately following the execution of hid_device_io_start() within the driver probe function. If the probe operation fails after \"io start\" has been initiated, this race condition will result in a UAF vulnerability. Fix the problem by calling hid_device_io_stop() before calling hid_hw_stop().", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68361", "url": "https://ubuntu.com/security/CVE-2026-68361", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hwmon: (corsair-psu) Stop device IO before calling hid_hw_stop hid_hw_stop() does not stop the device IO. This results in a race condition between hid_input_report() and the point immediately following the execution of hid_device_io_start() within corsairpsu_probe(). If the probe operation fails after \"io start\" has been initiated, this race condition will result in a uaf vulnerability [1]. CPU0\t\t\t\tCPU1 ====\t\t\t\t==== corsairpsu_probe() hid_device_io_start() ... unlock driver_input_lock hid_hw_stop() kfree(hidraw)\t\t\t__hid_input_report() \t\t\t\t ... acquire driver_input_lock \t\t\t\t hid_report_raw_event() \t\t\t\t hidraw_report_event() \t\t\t\t ... access hidraw's list_lock // trigger uaf Consequently, when corsairpsu_probe() fails and hid_hw_stop() needs to be executed, the io_started flag is first cleared while holding the driver_input_lock to prevent potential race conditions involving input reports. [1] BUG: KASAN: slab-use-after-free in rt_spin_lock+0x83/0x400 kernel/locking/spinlock_rt.c:56 Call Trace: hidraw_report_event+0x5d/0x3a0 drivers/hid/hidraw.c:577 hid_report_raw_event+0x311/0x1730 drivers/hid/hid-core.c:2076 __hid_input_report drivers/hid/hid-core.c:2152 [inline] hid_input_report+0x44e/0x580 drivers/hid/hid-core.c:2174 hid_irq_in+0x47e/0x6d0 drivers/hid/usbhid/hid-core.c:286 __usb_hcd_giveback_urb+0x3b3/0x5e0 drivers/usb/core/hcd.c:1657 dummy_timer+0x8a9/0x47d0 drivers/usb/gadget/udc/dummy_hcd.c:2005 Allocated by task 10: hidraw_connect+0x57/0x430 drivers/hid/hidraw.c:606 hid_connect+0x5bf/0x19d0 drivers/hid/hid-core.c:2277 hid_hw_start+0xa8/0x120 drivers/hid/hid-core.c:2387 corsairpsu_probe+0xd9/0x3c0 drivers/hwmon/corsair-psu.c:782 Freed by task 10: hidraw_disconnect+0x4f/0x60 drivers/hid/hidraw.c:662 hid_disconnect drivers/hid/hid-core.c:2362 [inline] hid_hw_stop+0x101/0x1e0 drivers/hid/hid-core.c:2407 corsairpsu_probe+0x327/0x3c0 drivers/hwmon/corsair-psu.c:826 Fix the problem by calling hid_device_io_stop() before calling hid_hw_stop(). [groeck: Updated subject and description; call hid_device_io_stop() only if IO has been started]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68362", "url": "https://ubuntu.com/security/CVE-2026-68362", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix NULL pointer dereference in ath11k_hal_srng_access_begin In ATH11K_QMI_EVENT_FW_READY, ATH11K_FLAG_REGISTERED is set unconditionally even when ath11k_core_qmi_firmware_ready() fails. This leaves the driver in an inconsistent state where initialization is considered complete although the firmware ready handling did not finish successfully. During the subsequent SSR, the driver enters the restart path based on this incorrect state and dereferences uninitialized srng members, resulting in a NULL pointer dereference. Call trace: ath11k_hal_srng_access_begin+0xc/0x60 [ath11k] (P) ath11k_ce_cleanup_pipes+0x17c/0x180 [ath11k] ath11k_core_restart+0x40/0x168 [ath11k] Fix this by: - skipping firmware_ready if ATH11K_FLAG_REGISTERED is already set - setting ATH11K_FLAG_REGISTERED only when firmware_ready succeeds - setting ATH11K_FLAG_QMI_FAIL and aborting the FW_READY handling on error Tested-on: WCN6750 hw1.0 AHB WLAN.MSL.2.0.c2-00204-QCAMSLSWPLZ-1", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68363", "url": "https://ubuntu.com/security/CVE-2026-68363", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath9k: hif_usb: don't dereference hif_dev after re-arming firmware request ath9k_hif_request_firmware() re-arms an asynchronous firmware load via request_firmware_nowait(), passing hif_dev as the completion context, and then still dereferences hif_dev: \tdev_info(&hif_dev->udev->dev, \"ath9k_htc: Firmware %s requested\\n\", \t\t hif_dev->fw_name); The re-armed callback ath9k_hif_usb_firmware_cb() runs on the \"events\" workqueue and, when the firmware is missing, walks the retry chain into ath9k_hif_usb_firmware_fail() -> complete_all(&hif_dev->fw_done). That releases the wait_for_completion(&hif_dev->fw_done) in a concurrent ath9k_hif_usb_disconnect(), which then kfree()s hif_dev. The trailing dev_info() in the frame that re-armed the request can therefore read freed memory (hif_dev->udev, the first field of struct hif_device_usb): BUG: KASAN: slab-use-after-free in ath9k_hif_request_firmware Read of size 8 ... by task kworker/... ath9k_hif_request_firmware ath9k_hif_usb_firmware_cb drivers/net/wireless/ath/ath9k/hif_usb.c:1247 request_firmware_work_func Allocated by ...: ath9k_hif_usb_probe drivers/net/wireless/ath/ath9k/hif_usb.c Freed by ...: ath9k_hif_usb_disconnect -> kfree drivers/net/wireless/ath/ath9k/hif_usb.c The fw_done barrier only makes disconnect wait for the firmware chain to *terminate*; it does not protect the outer ath9k_hif_request_firmware() frame that re-armed the request and keeps touching hif_dev afterwards. Drop the post-request dev_info(): it is the only use of hif_dev after the async request is armed, and it is purely informational (the dev_err() on the failure path runs only when request_firmware_nowait() did not arm a callback, so hif_dev is still alive there). This was first reported by syzbot as a single, non-reproduced crash that was later auto-obsoleted, and was independently rediscovered by the reFuzz fuzzer, which produced a C reproducer (USB-gadget connect/disconnect of an ath9k_htc device whose firmware download fails). The vulnerable code is unchanged and still present in v7.1-rc6, where the slab-use-after-free reproduces under KASAN once the (sub-microsecond) race window is widened.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68365", "url": "https://ubuntu.com/security/CVE-2026-68365", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: io_edgeport: cap received transmit credits The interrupt-status packet reports transmit credits returned by the device. edge_interrupt_callback() adds the 16-bit value to txCredits without checking maxTxCredits. edge_write() uses txCredits minus the software FIFO count as the amount of data that fits. Since the FIFO is allocated with maxTxCredits bytes, txCredits exceeding maxTxCredits can cause OOB write in ring buffer. Cap accumulated credits at maxTxCredits. Conforming devices should never hit the cap.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68366", "url": "https://ubuntu.com/security/CVE-2026-68366", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: uvc: clamp SEND_RESPONSE length to the response buffer uvc_send_response() builds the UVC control response from a user-supplied struct uvc_request_data: \treq->length = min_t(unsigned int, uvc->event_length, data->length); \t... \tmemcpy(req->buf, data->data, req->length); req->length is clamped to uvc->event_length, which is taken from the host control request wLength (up to UVC_MAX_REQUEST_SIZE, 64), and to data->length, which comes from the UVCIOC_SEND_RESPONSE ioctl and is only checked for being negative. The source buffer data->data is only 60 bytes, so a response with uvc->event_length and data->length both greater than 60 makes memcpy() read past the end of data->data. Clamp req->length to sizeof(data->data) as well.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64583", "url": "https://ubuntu.com/security/CVE-2026-64583", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: udc: bdc: free IRQ and drain func_wake_notify before teardown The Broadcom BDC UDC driver registers its IRQ handler with devm_request_irq() in bdc_udc_init(), so the IRQ is released by devm only after bdc_remove() returns. devm releases resources in reverse LIFO order, but bdc_remove() runs bdc_udc_exit() and bdc_hw_exit() -> bdc_mem_free() manually before returning: bdc_udc_exit() tears down individual endpoint objects via bdc_free_ep(), while bdc_hw_exit() -> bdc_mem_free() frees and NULLs the DMA-coherent status-report ring (bdc->srr.sr_bds) and kfree()s bdc->bdc_ep_array. Both happen while the IRQ handler (bdc_udc_interrupt, requested with IRQF_SHARED) remains deliverable in the window up to the post-remove devm free_irq(). On receipt of a shared interrupt in that window, bdc_udc_interrupt() dereferences bdc->srr.sr_bds[bdc->srr.dqp_index] (NULL or freed DMA) and dispatches sr_handler callbacks that index into bdc_ep_array, causing a NULL-deref or use-after-free. The same window affects the delayed_work bdc->func_wake_notify, which is armed from the IRQ handler via bdc_sr_uspc() -> handle_link_state_change() -> schedule_delayed_work() and may self-rearm from its own callback bdc_func_wake_timer(). No cancel exists anywhere in the driver, so a queued work item that fires after bdc_remove() returns and the bdc structure is devm-freed dereferences freed memory. Replace devm_request_irq() with request_irq() and add an explicit free_irq(bdc->irq, bdc) in bdc_remove(). Clear BDC_GIE before free_irq() to stop the device from asserting interrupts, then free_irq() drains any in-flight handler, then cancel_delayed_work_sync() drains the func_wake_notify delayed work. This ordering ensures the IRQ handler and delayed work cannot interfere with the subsequent endpoint and DMA teardown in bdc_udc_exit() and bdc_hw_exit(). Wire the matching free_irq() into the bdc_udc_init() error path so the IRQ is released on probe failure, and route the bdc_init_ep() failure through err0 instead of returning directly. This issue was found by an in-house static analysis tool.", "cve_priority": "low", "cve_public_date": "2026-08-06 08:16:00 UTC" }, { "cve": "CVE-2026-68368", "url": "https://ubuntu.com/security/CVE-2026-68368", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_ncm: validate datagram bounds in ncm_unwrap_ntb() When unpacking host-supplied NTBs, ncm_unwrap_ntb() checks datagram length against frame_max but does not verify that the datagram fits within the declared block length. Additionally, when decoding multiple NTBs from a single socket buffer, subsequent block lengths are not checked against the actual remaining buffer data. With these checks missing, a malicious USB host can specify datagram offsets and lengths that point beyond the block, or supply secondary NTB headers declaring lengths larger than the buffer. skb_put_data() then copies adjacent kernel memory from skb_shared_info into the network skb. Fix this by verifying that sufficient buffer space remains for the NTB header before parsing, handling zero-length block declarations, ensuring that block lengths never exceed the remaining buffer space, and verifying that each datagram payload stays strictly within the block boundary.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68369", "url": "https://ubuntu.com/security/CVE-2026-68369", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: printer: fix infinite loop in printer_read() printer_read() uses the same variable for the requested copy size and the number of bytes actually copied to user space. copy_to_user() returns the number of bytes not copied, so when it fails to copy anything, the computed copied length becomes zero. In that case len, buf, current_rx_bytes and current_rx_buf are left unchanged. If RX data is available and the user buffer remains unwritable, the read loop can repeat indefinitely. Track the copied length separately and return -EFAULT, or the number of bytes already copied, if an iteration makes no progress.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64584", "url": "https://ubuntu.com/security/CVE-2026-64584", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_midi: cancel pending IN work before freeing the midi object The f_midi driver embeds a work item (midi->work) whose handler, f_midi_in_work(), dereferences the enclosing struct f_midi through container_of(). This work is armed from two sites: f_midi_complete(), on a normal IN-endpoint completion, and f_midi_in_trigger(), on an ALSA rawmidi output-stream start. Neither f_midi_disable() nor f_midi_unbind() cancels midi->work. f_midi_disable() only disables the endpoints and drains the in_req_fifo; it does not synchronize the work item, and the sound card is released asynchronously to the final free of the midi object. The midi object is reference-counted (midi->free_ref) and is freed in f_midi_free() only once both the usb_function reference and the rawmidi private_data reference have been dropped. In f_midi_unbind(), f_midi_disable() runs before the sound card is released, so while the USB endpoints are already disabled the rawmidi device is still usable by an open substream. A concurrent userspace write on such a substream can reach f_midi_in_trigger() and queue midi->work again after f_midi_disable() has returned. A work item armed this way may still be pending when the last reference drops and f_midi_free() proceeds to kfree(midi), letting f_midi_in_work() dereference the struct after it has been freed, a use-after-free. For this reason cancelling midi->work in f_midi_disable() would not be sufficient: the ALSA trigger path can rearm the work after disable() returns. Cancelling at the refcount-zero free site is the boundary after which neither arming source can survive, because by then both references that keep the midi object alive have been dropped: the USB endpoints are already disabled and the rawmidi device has been released. Fix this by calling cancel_work_sync(&midi->work) in the refcount-zero block of f_midi_free(), before the embedded work_struct is freed along with the rest of the structure. opts->lock is a sleeping mutex, so calling cancel_work_sync() under it is permitted, and the handler takes midi->transmit_lock rather than opts->lock, so no self-deadlock can occur while it waits for a running instance of the work to finish. This issue was found by an in-house static analysis tool.", "cve_priority": "medium", "cve_public_date": "2026-08-06 08:16:00 UTC" }, { "cve": "CVE-2026-68370", "url": "https://ubuntu.com/security/CVE-2026-68370", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: dummy_hcd: prevent fifo_req reuse during giveback dummy_hcd embeds a single shared usb_request (dum->fifo_req) that the \"emulated single-request FIFO\" fast-path in dummy_queue() reuses for small IN transfers: it copies the caller's request into it (req->req = *_req) and queues it, treating list_empty(&fifo_req.queue) as \"the slot is free\". The completion side (dummy_timer/transfer/nuke/dummy_dequeue) follows the standard pattern: list_del_init(&req->queue) unlinks the request, then the lock is dropped and usb_gadget_giveback_request() invokes req->complete(). But list_del_init() makes fifo_req.queue look empty *before* the completion callback returns, so a concurrent dummy_queue() on another CPU sees the slot as free, reuses fifo_req and runs req->req = *_req -- overwriting req->complete while dummy_timer is mid-calling it. The indirect call then jumps to a clobbered pointer, causing a general protection fault / page fault in dummy_timer (syzkaller extid faf3a6cf579fc65591ca). The clobbering write is an in-bounds memcpy on a live shared object, so KASAN cannot flag it. Add a fifo_req_busy bit covering the shared request's whole lifetime: set it in dummy_queue() when the FIFO fast-path takes fifo_req (making it the fast-path guard, replacing the list_empty(&fifo_req.queue) test), and clear it after the completion callback has returned, via a dummy_giveback() helper used at all four gadget-request giveback sites. The shared slot can no longer be reused until its completion callback has finished.", "cve_priority": "low", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68373", "url": "https://ubuntu.com/security/CVE-2026-68373", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: at76c50x-usb: avoid length underflow in at76_guess_freq() at76_guess_freq() checks only that the received frame is at least a bare 802.11 header (24 bytes) before subtracting the fixed management-body offset: \tlen -= el_off; For both beacon and probe response frames, el_off is 36. If the frame is shorter than el_off, subtracting it causes the calculated IE length to wrap. The length is eventually passed to cfg80211_find_elem_match() as a very large unsigned value, so the element walk runs beyond the RX skb. This path is reached from at76_rx_tasklet() while scanning. If the device delivers a truncated beacon or probe response, the oversized IE length causes an out-of-bounds read during scanning. Skip the IE lookup if the frame does not reach the variable elements, before subtracting el_off.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64569", "url": "https://ubuntu.com/security/CVE-2026-64569", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mpls: fix NULL deref in mpls_valid_fib_dump_req() on CONFIG_INET=n On CONFIG_INET=n builds, mpls_valid_fib_dump_req() walks the parsed attribute table itself instead of calling ip_valid_fib_dump_req(). The RTA_OIF arm passes tb[RTA_OIF] to nla_get_u32() without checking it is present, so an RTM_GETROUTE dump for AF_MPLS with strict checking and no RTA_OIF hits a NULL dereference. RTM_GETROUTE is RTNL_KIND_GET, which rtnetlink_rcv_msg() permits without CAP_NET_ADMIN, so an unprivileged user can trigger it. 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:mpls_valid_fib_dump_req (net/mpls/af_mpls.c:2189) Call Trace: mpls_dump_routes (net/mpls/af_mpls.c:2236) netlink_dump (net/netlink/af_netlink.c:2331) __netlink_dump_start (net/netlink/af_netlink.c:2446) rtnetlink_rcv_msg (net/core/rtnetlink.c:7033) netlink_rcv_skb (net/netlink/af_netlink.c:2556) netlink_unicast (net/netlink/af_netlink.c:1345) netlink_sendmsg (net/netlink/af_netlink.c:1900) __sock_sendmsg (net/socket.c:790) ____sys_sendmsg (net/socket.c:2684) ___sys_sendmsg (net/socket.c:2738) __sys_sendmsg (net/socket.c:2770) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Skip unset attributes, as ip_valid_fib_dump_req() does.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68376", "url": "https://ubuntu.com/security/CVE-2026-68376", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: fix auth_hmacs array size in struct sctp_cookie The auth_hmacs array in struct sctp_cookie is supposed to store a complete SCTP_AUTH_HMAC_ALGO parameter, which consists of a struct sctp_paramhdr followed by N HMAC identifiers. However, the array size was calculated using an extra 2 bytes instead of sizeof(struct sctp_paramhdr), which is 4 bytes. When four HMAC identifiers are configured, the HMAC-ALGO parameter stored in the endpoint is larger than the auth_hmacs buffer in the cookie. As a result, sctp_association_init() copies beyond the end of auth_hmacs when initializing the association, corrupting the adjacent auth_chunks field. This can lead to an invalid HMAC identifier being accepted and later cause an out-of-bounds read in sctp_auth_get_hmac(). Fix the array size calculation by including the full SCTP parameter header size.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68377", "url": "https://ubuntu.com/security/CVE-2026-68377", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: act_tunnel_key: Defer dst_release to RCU callback Fix a race-condition use-after-free in tunnel_key_release_params(). The function releases the metadata_dst of the old params synchronously via dst_release() while deferring the params struct free with kfree_rcu(). A concurrent tunnel_key_act() reader on the datapath may still hold the old params pointer (under rcu_read_lock_bh) and proceed to call dst_clone(¶ms->tcft_enc_metadata->dst) after the writer's dst_release has already pushed the dst's rcuref to RCUREF_DEAD. zdi-disclosures@trendmicro.com produced a poc which i (and Victor) verified that KASAN reports: ================================================================== BUG: KASAN: slab-use-after-free in instrument_atomic_read_write include/linux/instrumented.h:112 BUG: KASAN: slab-use-after-free in atomic_sub_return_release include/linux/atomic/atomic-instrumented.h:326 BUG: KASAN: slab-use-after-free in __rcuref_put include/linux/rcuref.h:109 BUG: KASAN: slab-use-after-free in rcuref_put include/linux/rcuref.h:173 BUG: KASAN: slab-use-after-free in dst_release+0x5b/0x370 net/core/dst.c:168 Write of size 4 at addr ffff88806158de40 by task poc/9388 CPU: 0 UID: 0 PID: 9388 Comm: poc Tainted: G W 7.1.0-rc7 #7 PREEMPT(lazy) Tainted: [W]=WARN Hardware name: QEMU Ubuntu 25.10 PC v2 (i440FX + PIIX, + 10.1 machine, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:94 dump_stack_lvl+0x100/0x190 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 print_report+0x139/0x4ad mm/kasan/report.c:482 kasan_report+0xe4/0x1d0 mm/kasan/report.c:595 check_region_inline mm/kasan/generic.c:186 kasan_check_range+0x125/0x200 mm/kasan/generic.c:200 instrument_atomic_read_write include/linux/instrumented.h:112 atomic_sub_return_release include/linux/atomic/atomic-instrumented.h:326 __rcuref_put include/linux/rcuref.h:109 rcuref_put include/linux/rcuref.h:173 dst_release+0x5b/0x370 net/core/dst.c:168 refdst_drop include/net/dst.h:272 skb_dst_drop include/net/dst.h:284 skb_release_head_state+0x293/0x400 net/core/skbuff.c:1163 skb_release_all net/core/skbuff.c:1187 [..] Allocated by task 9391: kasan_save_stack+0x30/0x50 mm/kasan/common.c:57 kasan_save_track+0x14/0x30 mm/kasan/common.c:78 poison_kmalloc_redzone mm/kasan/common.c:398 __kasan_kmalloc+0x9a/0xb0 mm/kasan/common.c:415 kasan_kmalloc include/linux/kasan.h:263 __do_kmalloc_node mm/slub.c:5296 __kmalloc_noprof+0x2f1/0x830 mm/slub.c:5308 kmalloc_noprof include/linux/slab.h:954 kzalloc_noprof include/linux/slab.h:1188 offload_action_alloc+0x2f/0x130 net/core/flow_offload.c:35 tcf_action_offload_add_ex+0x1ba/0x880 net/sched/act_api.c:258 tcf_action_offload_add net/sched/act_api.c:293 tcf_action_init+0x66e/0xa20 net/sched/act_api.c:1547 tcf_action_add+0xf6/0x5d0 net/sched/act_api.c:2101 [..] Freed by task 9391: kasan_save_stack+0x30/0x50 mm/kasan/common.c:57 kasan_save_track+0x14/0x30 mm/kasan/common.c:78 kasan_save_free_info+0x3b/0x70 mm/kasan/generic.c:584 poison_slab_object mm/kasan/common.c:253 __kasan_slab_free+0x6b/0x90 mm/kasan/common.c:285 kasan_slab_free include/linux/kasan.h:235 slab_free_hook mm/slub.c:2689 slab_free mm/slub.c:6251 kfree+0x21f/0x6b0 mm/slub.c:6566 tcf_action_offload_add_ex+0x4ad/0x880 net/sched/act_api.c:284 tcf_action_offload_add net/sched/act_api.c:293 tcf_action_init+0x66e/0xa20 net/sched/act_api.c:1547 tcf_action_add+0xf6/0x5d0 net/sched/act_api.c:2101 The buggy address belongs to the object at ffff88806158de00 which belongs to the cache kmalloc-256 of size 256 The buggy address is located 64 bytes inside of freed 256-byte region [ffff88806158de00, ffff88806158df00) The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffff88806158d600 pfn:0x6158c head: order:1 mapcount:0 entire_map ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64578", "url": "https://ubuntu.com/security/CVE-2026-64578", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate compound request size before reading StructureSize2 When ksmbd validates a compound (chained) SMB2 request, ksmbd_smb2_check_message() reads pdu->StructureSize2 without first checking that the compound element is large enough to contain it. StructureSize2 is a 2-byte field at offset 64 (__SMB2_HEADER_STRUCTURE_SIZE) from the start of each element. The compound-walking logic only guarantees that a full 64-byte SMB2 header is present for the trailing element: when NextCommand is 0, len is reduced to the number of bytes remaining after next_smb2_rcv_hdr_off. A remote client can craft a compound request whose last element has exactly 64 bytes, so the 2-byte StructureSize2 read at offset 64 extends one byte past the receive buffer, producing a slab-out-of-bounds read. BUG: KASAN: slab-out-of-bounds in ksmbd_smb2_check_message (fs/smb/server/smb2misc.c:402) Read of size 2 at addr ffff888012ae31ac by task kworker/0:1/14 The buggy address is located 172 bytes inside of allocated 173-byte region Workqueue: ksmbd-io handle_ksmbd_work Call Trace: ... kasan_report (mm/kasan/report.c:595) ksmbd_smb2_check_message (fs/smb/server/smb2misc.c:402) handle_ksmbd_work (fs/smb/server/server.c:119) process_one_work (kernel/workqueue.c:3314) worker_thread (kernel/workqueue.c:3397) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) Reject any compound element that is too small to hold StructureSize2 before dereferencing it.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68381", "url": "https://ubuntu.com/security/CVE-2026-68381", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: pin conn during async oplock break notification smb2_oplock_break_noti() and smb2_lease_break_noti() store a ksmbd_conn pointer in an async ksmbd_work and then queue that work on ksmbd-io. The work only increments conn->r_count, which prevents teardown from passing the pending-request wait after the increment, but it does not pin the struct ksmbd_conn object. If connection teardown races with an oplock break notification, the last conn reference can be dropped before the queued worker finishes. The worker then uses the freed conn in ksmbd_conn_write() and ksmbd_conn_r_count_dec(). Take a real conn reference when publishing the conn pointer to the async work item, and drop it after the notification work has decremented r_count. Apply the same lifetime rule to lease break notification, which uses the same work->conn pattern.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68386", "url": "https://ubuntu.com/security/CVE-2026-68386", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Reject unhashed UDP sockets on sockmap update UDP sockets get SOCK_RCU_FREE set when (auto-)bound. This means sk_is_refcounted(unbound) = true, while sk_is_refcounted(bound) = false. Because sockmap accepts unbound UDP sockets, a BPF program can increment a socket's refcount via lookup. If the socket is subsequently bound, the transition from unbound to bound causes bpf_sk_release() to skip the decrement of the refcount, causing a memory leak. unreferenced object 0xffff88810bc2eb40 (size 1984): comm \"test_progs\", pid 2451, jiffies 4295320596 hex dump (first 32 bytes): 7f 00 00 01 7f 00 00 01 d2 04 1b b7 04 d2 00 00 ................ 02 00 01 40 00 00 00 00 00 00 00 00 00 00 00 00 ...@............ backtrace (crc bdee079d): kmem_cache_alloc_noprof+0x557/0x660 sk_prot_alloc+0x69/0x240 sk_alloc+0x30/0x460 inet_create+0x2ce/0xf80 __sock_create+0x25b/0x5c0 __sys_socket+0x119/0x1d0 __x64_sys_socket+0x72/0xd0 do_syscall_64+0xa1/0x5f0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Instead of special-casing for refcounted sockets, reject unhashed UDP sockets during sockmap updates, as there is no benefit to supporting those. This effectively reverts the commit under Fixes, with two exceptions: 1. sock_map_sk_state_allowed() maintains a fall-through `return true`. 2. In the spirit of commit b8b8315e39ff (\"bpf, sockmap: Remove unhash handler for BPF sockmap usage\"), the proto::unhash BPF handler is not reintroduced. Historical note: this issue is related to commit 67312adc96b5 (\"bpf: reject unhashed sockets in bpf_sk_assign\").", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68388", "url": "https://ubuntu.com/security/CVE-2026-68388", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb/client: handle overlapping allocated ranges in fallocate smb3_simple_fallocate_range() can skip holes when an allocated range returned by the server starts before the current fallocate offset. The skipped hole is not zero-filled, but fallocate still returns success. A later write to that hole may therefore fail with ENOSPC. The function queries allocated ranges so that it can preserve existing contents and write zeroes only into holes. However, the server may return a range that starts before the current fallocate offset. For example, assume the fallocate request is [100, 400) and the only allocated range returned by the server is [0, 200): Request: [100, 400) Server range: [ 0, 200) allocated Correct: [100, 200) allocated data, skip [200, 400) hole, zero-fill Current: [100, 300) skipped [300, 400) zero-filled afterwards The current code adds the full server range length, 200, to the current offset 100 and moves to 300. As a result, the hole in [200, 300) is skipped without being zero-filled. Fix this by advancing only over the part of the allocated range that overlaps the current fallocate offset. Ignore ranges that end before the current offset and reject ranges whose end offset overflows. This also prevents a malformed range length from causing an out-of-bounds zero-buffer read.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68389", "url": "https://ubuntu.com/security/CVE-2026-68389", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_qca: Clear memdump state on invalid dump size qca_controller_memdump() allocates qca->qca_memdump before processing the first dump packet. For a sequence-zero packet it then disables IBS, marks memdump collection active, and reads the advertised dump size. If the controller reports a zero dump size, the error path frees the local qca_memdump object and returns without clearing qca->qca_memdump or undoing the collection state. A later memdump work item initializes its local pointer from qca->qca_memdump and skips allocation when that pointer is non-NULL, so it can operate on freed memory. The stale collection and IBS-disabled flags can also leave waiters or later transmit handling blocked behind an aborted dump. Clear the saved pointer and memdump state before returning from the invalid-size path, matching the cleanup used when hci_devcd_init() fails. A static analysis checker reported the stale memdump state, and manual source review confirmed the invalid-size failure path.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68391", "url": "https://ubuntu.com/security/CVE-2026-68391", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: mgmt: hold reference for hci_conn in mgmt_pending_cmds Dereferencing RCU-protected pointers outside critical sections is invalid and may lead to UAF. Use of hci_conn in hci_sync callbacks also needs to hold refcount to avoid UAF. Take appropriate locks for hci_conn lookups, and take refcount for hci_conn pointers stored in mgmt_pending_cmd so that the pointer stays valid. When accessing conn->state, ensure hdev->lock is held to avoid data race.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68392", "url": "https://ubuntu.com/security/CVE-2026-68392", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: mgmt: fix locking in unpair_device/disconnect_sync Dereferencing RCU-protected pointers outside critical sections is invalid and may lead to UAF. Take hdev->lock for hci_conn lookup and hci_abort_conn(). Don't use RCU to ensure the conn is fully initialized at this point.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64573", "url": "https://ubuntu.com/security/CVE-2026-64573", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: qca: fix NVM tag length underflow in TLV parser In the TLV_TYPE_NVM branch of qca_tlv_check_data() the tag loop bound is \"while (idx < length - sizeof(struct tlv_type_nvm))\". \"length\" is a signed int from the firmware TLV header and sizeof(struct tlv_type_nvm) is a size_t (12), so \"length\" is converted to size_t and any firmware-supplied \"length\" < 12 makes the subtraction wrap to a huge value. The loop body then reads a 12-byte struct tlv_type_nvm past the end of the short vmalloc'd firmware buffer (and the EDL_TAG_ID_* handlers can write past it). Rewrite the bound as \"idx + sizeof(struct tlv_type_nvm) <= length\"; both operands are non-negative, so it no longer underflows and a \"length\" too small for one record correctly skips the loop. BUG: KASAN: vmalloc-out-of-bounds in qca_download_firmware.isra.0 (drivers/bluetooth/btqca.c:421) Read of size 2 at addr ffffc900000e5004 by task kworker/u9:0/52 Workqueue: hci0 hci_power_on Call Trace: ... kasan_report (mm/kasan/report.c:595) qca_download_firmware.isra.0 (drivers/bluetooth/btqca.c:421 drivers/bluetooth/btqca.c:617) qca_uart_setup (drivers/bluetooth/btqca.c:948) qca_setup (drivers/bluetooth/hci_qca.c:2029) hci_uart_setup (drivers/bluetooth/hci_ldisc.c:438) hci_dev_open_sync (net/bluetooth/hci_sync.c:5227) hci_power_on (net/bluetooth/hci_core.c:920) process_one_work (kernel/workqueue.c:3322) worker_thread (kernel/workqueue.c:3486) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245)", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68449", "url": "https://ubuntu.com/security/CVE-2026-68449", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ata: sata_dwc_460ex: fix infinite loop in NCQ tag completion bit-scanning The hand-rolled bit-scanning loop in the NCQ completion path has an infinite loop bug. When tag_mask has only high bits set (e.g. 0x80000000), the inner while loop left-shifts tag_mask until it overflows to 0. At that point !(0 & 1) is always true and 0 <<= 1 stays 0, causing an infinite loop in hardirq context with a spinlock held. Replace the open-coded bit-scanning with __ffs() which correctly finds the least significant set bit and is bounded by the width of the argument.", "cve_priority": "medium", "cve_public_date": "2026-08-12 01:17:00 UTC" }, { "cve": "CVE-2026-68395", "url": "https://ubuntu.com/security/CVE-2026-68395", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ata: sata_dwc_460ex: enable SATA interrupts only after IRQ handler is registered sata_dwc_enable_interrupts() is called before platform_get_irq() and ata_host_activate(), leaving the SATA controller's interrupt mask enabled without a registered handler. If a later step fails (irq request, phy init, etc.) or if the controller asserts an interrupt during probe, the irq line may fire with no handler, causing a spurious interrupt storm. Move sata_dwc_enable_interrupts() after ata_host_activate() so that interrupts are only unmasked once the handler is registered and the core is fully initialized.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68397", "url": "https://ubuntu.com/security/CVE-2026-68397", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/iucv: take a reference on the socket found in afiucv_hs_rcv() afiucv_hs_rcv() looks up the destination socket under iucv_sk_list.lock, drops the lock, and then passes the socket to the afiucv_hs_callback_*() handlers without holding a reference. AF_IUCV sockets are not RCU-protected and are freed synchronously by iucv_sock_kill() -> sock_put(), so a concurrent close can free the socket in the window between read_unlock() and the handler, which then dereferences freed memory (for example sk->sk_data_ready() in afiucv_hs_callback_syn()). Take a reference with sock_hold() while the socket is still on the list and release it with sock_put() once the handler has run.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64572", "url": "https://ubuntu.com/security/CVE-2026-64572", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: fib: free fib_alias with kfree_rcu() on insert error path fib_table_insert() publishes new_fa into the leaf's fa_list with fib_insert_alias() before calling the fib entry notifiers. When a notifier fails, the error path removes new_fa with fib_remove_alias() (hlist_del_rcu) and frees it right away with kmem_cache_free(). fib_table_lookup() walks that list under rcu_read_lock() only, so a concurrent lookup that already reached new_fa keeps reading it after the free: BUG: KASAN: slab-use-after-free in fib_table_lookup (net/ipv4/fib_trie.c:1601) Read of size 1 at addr ffff88810676d4eb by task exploit/297 Call Trace: fib_table_lookup (net/ipv4/fib_trie.c:1601) ip_route_output_key_hash_rcu (net/ipv4/route.c:2814) ip_route_output_key_hash (net/ipv4/route.c:2705) __ip4_datagram_connect (net/ipv4/datagram.c:49) udp_connect (net/ipv4/udp.c:2144) __sys_connect (net/socket.c:2167) __x64_sys_connect (net/socket.c:2173) do_syscall_64 entry_SYSCALL_64_after_hwframe which belongs to the cache ip_fib_alias of size 56 Triggering the error path needs CAP_NET_ADMIN and a registered fib notifier that can reject a route; a netdevsim device whose IPv4 FIB resource is exhausted is enough. Free new_fa with alias_free_mem_rcu(), as fib_table_delete() already does for a fib_alias removed from the trie.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68398", "url": "https://ubuntu.com/security/CVE-2026-68398", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ppp: defer channel free to an RCU grace period to fix pppol2tp RX UAF pppol2tp_recv() runs in the L2TP UDP-encap softirq RX path: l2tp_udp_encap_recv() -> l2tp_recv_common() -> pppol2tp_recv() -> ppp_input(&po->chan) It runs under rcu_read_lock() holding only an l2tp_session reference and takes NO reference on the internal PPP channel (struct channel, chan->ppp) that ppp_input() dereferences. The pppox socket is SOCK_RCU_FREE, so 'po' and the embedded ppp_channel are RCU-safe. But the internal struct channel is a separate allocation that ppp_release_channel() frees with a plain kfree(): close(data socket) -> pppol2tp_release() -> pppox_unbind_sock() -> ppp_unregister_channel() -> ppp_release_channel() -> kfree(pch) For a channel that is bound (PPPIOCGCHAN) but not attached to a ppp unit (no PPPIOCCONNECT, pch->ppp == NULL) and not bridged, teardown skips both ppp_disconnect_channel()'s synchronize_net() and ppp_unbridge_channels()'s synchronize_rcu(), so the kfree() has no grace period. rcu_read_lock() in pppol2tp_recv() does not protect against a plain kfree(), so an in-flight ppp_input() on one CPU can dereference the channel just freed by close() on another CPU. The bug is reachable by an unprivileged user. Defer the channel free to an RCU callback via call_rcu() so the grace period fences any in-flight ppp_input(). The disconnect and unbridge teardown paths already fence with synchronize_net()/synchronize_rcu(); call_rcu() does the same here without stalling the close() path.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68402", "url": "https://ubuntu.com/security/CVE-2026-68402", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: bound element ID read when checking non-inheritance cfg80211_is_element_inherited() reads the first data octet of the candidate element (id = elem->data[0]) to look it up in an extension non-inheritance list. It does so after testing elem->id, but without verifying that the element actually has a data octet. A zero-length extension element (WLAN_EID_EXTENSION with length 0) therefore makes it read one octet past the end of the element. _ieee802_11_parse_elems_full() runs this check for every element of a frame once a non-inheritance context exists -- e.g. while parsing a per-STA profile of a Multi-Link element in a (re)association response, or a non-transmitted BSS profile -- so a crafted frame from an AP can trigger a one-octet slab-out-of-bounds read during element parsing: BUG: KASAN: slab-out-of-bounds in cfg80211_is_element_inherited Read of size 1 ... in net/wireless/scan.c Return early (treat the element as inherited) when an extension element carries no data, mirroring the existing handling of empty ID lists. The bug was found by fuzzing ieee802_11_parse_elems_full() under KASAN.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68403", "url": "https://ubuntu.com/security/CVE-2026-68403", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: initialize SDIO data work before cleanup brcmf_sdio_probe() stores the newly allocated bus in sdiodev->bus before allocating the ordered workqueue. If that allocation fails, the function jumps to fail and calls brcmf_sdio_remove(). brcmf_sdio_remove() unconditionally cancels bus->datawork. Initialize the work item before the first failure path that can reach brcmf_sdio_remove(), so the cleanup path always observes a valid work object. This issue was found by our static analysis tool and then confirmed by manual review of the probe error path and the remove-time work drain. The problem pattern is an early setup failure that reaches a cleanup helper which cancels an embedded work item before its initializer has run. A QEMU PoC forced alloc_ordered_workqueue() to fail at the same point in brcmf_sdio_probe(), before INIT_WORK(&bus->datawork) is reached. The resulting fail path calls brcmf_sdio_remove(), and DEBUG_OBJECTS reports the invalid work drain with brcmf_sdio_probe() and brcmf_sdio_remove() in the stack.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68405", "url": "https://ubuntu.com/security/CVE-2026-68405", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: free AP_VLAN bc_buf SKBs outside IRQ lock ieee80211_do_stop() removes AP_VLAN packets from the parent AP ps->bc_buf while holding ps->bc_buf.lock with IRQs disabled. It then calls ieee80211_free_txskb() before dropping the lock. ieee80211_free_txskb() is not just a passive SKB release. For SKBs with TX status state it can report a dropped frame through cfg80211/nl80211, and that path can reach netlink tap transmit. This is the same reason the pending queue cleanup in ieee80211_do_stop() already unlinks SKBs under the queue lock and frees them after IRQ state is restored. The buggy scenario involves two paths, with each column showing the order within that path: AP_VLAN management TX: AP_VLAN stop: 1. attach ACK-status state 1. clear the running state 2. queue a multicast SKB on 2. take ps->bc_buf.lock with IRQs parent ps->bc_buf disabled 3. unlink the AP_VLAN SKB 4. call ieee80211_free_txskb() Unlink matching AP_VLAN SKBs from ps->bc_buf under the existing lock, but move them to a local free queue. Drop the lock and restore IRQ state before calling ieee80211_free_txskb(). WARNING: kernel/softirq.c:430 at __local_bh_enable_ip", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68406", "url": "https://ubuntu.com/security/CVE-2026-68406", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: validate PMSR FTM preamble range PMSR FTM request parsing accepts preamble values outside the enumerated nl80211 preamble range. Reject out-of-range values before using them in the parser capability bit test using the policy. [drop unnecessary check]", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68407", "url": "https://ubuntu.com/security/CVE-2026-68407", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: nl80211: free RNR data on MBSSID mismatch nl80211_parse_beacon() rejects EMA RNR data when there are fewer RNR entries than MBSSID entries. The rejected RNR allocation has not been attached to the beacon data yet, so free it before returning the error.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64571", "url": "https://ubuntu.com/security/CVE-2026-64571", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: p54: validate RX frame length in p54_rx_eeprom_readback() p54_rx_eeprom_readback() copies the requested EEPROM slice out of a device-supplied readback frame without checking that the skb actually holds that many bytes. Commit da1b9a55ff11 (\"wifi: p54: prevent buffer-overflow in p54_rx_eeprom_readback()\") closed the destination overflow by copying a fixed priv->eeprom_slice_size (and rejecting a mismatched advertised len), but the source side is still unbounded: nothing verifies the frame is long enough to supply that many bytes. A malicious USB device can send a short frame whose advertised len matches priv->eeprom_slice_size while the payload is truncated. The equality check passes and memcpy() reads past the end of the skb, leaking adjacent heap: BUG: KASAN: slab-out-of-bounds in p54_rx (drivers/net/wireless/intersil/p54/txrx.c:507) Read of size 1016 at addr ffff88800f077114 by task swapper/0/0 Call Trace: ... __asan_memcpy (mm/kasan/shadow.c:105) p54_rx (drivers/net/wireless/intersil/p54/txrx.c:507) p54u_rx_cb (drivers/net/wireless/intersil/p54/p54usb.c:163) __usb_hcd_giveback_urb (drivers/usb/core/hcd.c:1657) dummy_timer (drivers/usb/gadget/udc/dummy_hcd.c:2005) ... The buggy address belongs to the object at ffff88800f0770c0 which belongs to the cache skbuff_small_head of size 704 The buggy address is located 84 bytes inside of allocated 704-byte region [ffff88800f0770c0, ffff88800f077380) Check that the slice fits in the skb before copying.", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68410", "url": "https://ubuntu.com/security/CVE-2026-68410", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: libertas: fix memory leak in helper_firmware_cb() helper_firmware_cb() neglects to free the single-stage firmware image after a successful async load, leading to a memory leak in the USB firmware-download path. Fix this memory leak by calling release_firmware() immediately after lbs_fw_loaded() returns. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in the current wireless tree. An x86_64 allyesconfig build showed no new warnings. As we do not have compatible Libertas USB hardware for exercising this firmware-download path, no runtime testing was able to be performed.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68411", "url": "https://ubuntu.com/security/CVE-2026-68411", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211_hwsim: clamp virtio RX length before skb_put hwsim_virtio_rx_work() passes the virtqueue used-ring length reported by the device straight to skb_put() on a fixed-size receive skb. A backend reporting a length larger than the skb tailroom drives skb_put() past the buffer end and hits skb_over_panic() -- a host-triggerable guest panic (denial of service). Clamp the length to the skb's available room before skb_put(). A conforming device never reports more than the posted buffer size, so valid frames are unaffected; a truncated over-report then fails the length/header checks in hwsim_virtio_handle_cmd() and is dropped, so truncating rather than dropping here cannot be turned into a parsing problem.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68413", "url": "https://ubuntu.com/security/CVE-2026-68413", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ipw2100: fix potential memory leak in ipw2100_pci_init_one() The memory allocated in the ipw2100_alloc_device() function is not freed in some of the error paths in ipw2100_pci_init_one(). Fix that by converting the direct return into a goto to the error path return. The error path when pci_enable_device() fails cannot jump to fail, since at this point priv is not set, so perform error handling inline.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68414", "url": "https://ubuntu.com/security/CVE-2026-68414", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: cancel sched scan results work on unregister cfg80211_sched_scan_results() can queue rdev->sched_scan_res_wk from a driver result notification while a scheduled scan request is present. The work callback recovers the containing cfg80211_registered_device and then locks the wiphy and walks the scheduled-scan request list. wiphy_unregister() already makes the wiphy unreachable and drains rdev work items before cfg80211_dev_free() can release the object, but it does not drain sched_scan_res_wk. A queued or running result work item can therefore cross the unregister/free boundary and access freed rdev state. The buggy scenario involves two paths, with each column showing the order within that path: scheduled-scan result path: unregister/free path: 1. cfg80211_sched_scan_results() 1. interface teardown stops and queues rdev->sched_scan_res_wk. removes the scheduled scan request. 2. cfg80211_wq starts the work 2. wiphy_unregister() drains other item and recovers rdev. rdev work items. 3. The worker locks rdev->wiphy 3. cfg80211_dev_free() destroys and and walks rdev state. frees rdev. Cancel sched_scan_res_wk in wiphy_unregister() alongside the other rdev work items. cancel_work_sync() removes a pending result notification and waits for an already running callback, so cfg80211_dev_free() cannot free rdev while this work item is still active. Validation reproduced this kernel report: BUG: KASAN: use-after-free in cfg80211_sched_scan_results_wk+0x4a6/0x530 Workqueue: cfg80211 cfg80211_sched_scan_results_wk [cfg80211] Read of size 8 Call trace: dump_stack_lvl+0x66/0xa0 print_report+0xce/0x630 cfg80211_sched_scan_results_wk+0x4a6/0x530 srso_alias_return_thunk+0x5/0xfbef5 __virt_addr_valid+0x224/0x430 kasan_report+0xac/0xe0 lockdep_hardirqs_on_prepare+0xea/0x1a0 process_one_work+0x8d0/0x18f0 (kernel/workqueue.c:3212) lock_is_held_type+0x8f/0x100 worker_thread+0x5ad/0xfd0 __kthread_parkme+0xc6/0x200 kthread+0x31e/0x410 trace_hardirqs_on+0x1a/0x170 ret_from_fork+0x576/0x810 __switch_to+0x57e/0xe20 __switch_to_asm+0x33/0x70 ret_from_fork_asm+0x1a/0x30", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64579", "url": "https://ubuntu.com/security/CVE-2026-64579", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm: policy: preallocate inexact bins before xfrm_hash_rebuild reinsert xfrm_hash_rebuild()'s first loop preallocates the bins/chains the reinsert loop needs, so the reinsert (after hlist_del_rcu()) cannot allocate or fail. But its guard is inverted: it skips policies with prefixlen < threshold and preallocates for the rest. prefixlen < threshold is exactly when policy_hash_bysel() returns NULL and the reinsert takes the allocating xfrm_policy_inexact_insert() path. So the loop preallocates for the exact policies (which never allocate) and skips the inexact ones, whose bin/node is then allocated GFP_ATOMIC during reinsert. On failure the error path only WARN_ONCE()s and continues, leaving a poisoned bydst node; the next rebuild's hlist_del_rcu() dereferences LIST_POISON2 and takes a GPF. Reachable under memory pressure, deterministic via failslab. Invert the guard so preallocation covers exactly the reinserted policies; the reinsert then allocates nothing and cannot fail. Crash: Oops: general protection fault, probably for non-canonical address 0xfbd59c0000000024: 0000 [#1] SMP KASAN NOPTI KASAN: maybe wild-memory-access in range [0xdead...] ... Workqueue: events xfrm_hash_rebuild RIP: 0010:xfrm_hash_rebuild+0x5b3/0x1190 RAX: dead000000000122 (LIST_POISON2 + offset) ... Call Trace: hlist_del_rcu (include/linux/rculist.h:599) xfrm_hash_rebuild (net/xfrm/xfrm_policy.c:1365) process_one_work (kernel/workqueue.c:3322) worker_thread (kernel/workqueue.c:3486) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) ... Kernel panic - not syncing: Fatal exception in interrupt", "cve_priority": "medium", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-64580", "url": "https://ubuntu.com/security/CVE-2026-64580", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfrm6: clear dst.dev on error to avoid double netdev_put in xfrm6_fill_dst() On the error path where in6_dev_get(dev) returns NULL, xfrm6_fill_dst() releases the device reference with netdev_put() but leaves xdst->u.dst.dev set. dst_destroy() later calls netdev_put(dst->dev) again, so the same net_device reference is released twice, underflowing its refcount (ref_tracker WARNING + \"unregister_netdevice: waiting for to become free\"). Clear xdst->u.dst.dev after the netdev_put(), the same way the XFRM device-offload paths xfrm_dev_state_add() and xfrm_dev_policy_add() in net/xfrm/xfrm_device.c NULL ->dev when releasing the reference on error. ref_tracker: reference already released. ref_tracker: allocated in: xfrm6_fill_dst (net/ipv6/xfrm6_policy.c:86) ... udpv6_sendmsg (net/ipv6/udp.c:1696) ... ref_tracker: freed in: xfrm6_fill_dst (net/ipv6/xfrm6_policy.c:90) ... WARNING: lib/ref_tracker.c:322 at ref_tracker_free+0x58b/0x780 dst_destroy (net/core/dst.c:115) rcu_core handle_softirqs ...", "cve_priority": "high", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68416", "url": "https://ubuntu.com/security/CVE-2026-68416", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mtd: fix double free and WARN_ON in add_mtd_device() error paths When device_register() or mtd_nvmem_add() fails inside add_mtd_device() for a partition, the error handling triggers mtd_release() via put_device() or device_unregister(). mtd_release() calls release_mtd_partition() which frees the mtd_info structure. However, callers such as mtd_add_partition() and add_mtd_partitions() also call free_partition() in their error paths, resulting in a double free. Additionally, release_mtd_partition() hits WARN_ON(!list_empty( &mtd->part.node)) because the partition node is still linked in the parent's partitions list when the release callback fires from the add_mtd_device() error path. Fix this by overriding dev->type and dev->release before put_device() in the error paths, so that device_release() invokes a no-op function instead of mtd_release(). For the mtd_nvmem_add() failure case, device_unregister() is replaced with device_del() to separate the device removal from the final kobject reference drop, allowing the override to take effect before put_device() is called. The callers' error paths (list_del + free_partition) remain the sole owners of mtd_info lifetime on add_mtd_device() failure, which is the expected contract. The normal partition teardown path is not affected: del_mtd_device() goes through kref_put() -> mtd_device_release() -> device_unregister() with dev->type still set to &mtd_devtype, so mtd_release() -> release_mtd_partition() continues to work correctly for the regular removal case.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68417", "url": "https://ubuntu.com/security/CVE-2026-68417", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/siw: publish QP after initialization siw_create_qp() currently calls siw_qp_add() before the queues, CQ pointers, state, completion, and device list entry are ready. A QPN lookup can therefore reach a QP that is still being constructed. Move siw_qp_add() to the end of siw_create_qp(), after QP initialization and before adding the QP to the siw device list.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68419", "url": "https://ubuntu.com/security/CVE-2026-68419", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/irdma: Prevent rereg_mr for non-mem regions When a QP/CQ/SRQ is created, a two step process is used where the buffer is allocated in userspace and explicitly registered with the normal reg_mr mechanism prior to creating the actual QP/CQ/SRQ object. These special registrations are indicated via an ABI field so the driver knows that they do not have a valid mkey and to skip the actual CQP command submission. Since these are real MR objects from the core's perspective, it is possible for a user application to invoke rereg_mr on them and cause a real CQP op to be emitted with the zero-initialized mkey value of 0. Fix this by preventing rereg_mr on these special regions.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-68444", "url": "https://ubuntu.com/security/CVE-2026-68444", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_ffa: Fix NULL dereference in ffa_partition_info_get() ffa_partition_info_get() passes uuid_str directly to uuid_parse() without a NULL check. When a caller passes NULL, uuid_parse() -> __uuid_parse() -> uuid_is_valid() dereferences the pointer, causing a kernel panic: | Unable to handle kernel NULL pointer dereference at virtual address | 0000000000000040 | pc : uuid_parse+0x40/0xac | lr : ffa_partition_info_get+0x1c/0x94 [arm_ffa] Add a NULL guard before uuid_parse() so a NULL argument returns -ENODEV instead of crashing. Callers are expected to always supply a valid partition UUID, so NULL is not a supported input.", "cve_priority": "medium", "cve_public_date": "2026-08-12 00:17:00 UTC" }, { "cve": "CVE-2026-68422", "url": "https://ubuntu.com/security/CVE-2026-68422", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix root leak if its reloc root is unexpected in merge_reloc_roots() If we have an unexpected reloc_root for our root, we jump to the out label but never drop the reference we obtained for root, resulting in a leak. Add a missing btrfs_put_root() call.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64567", "url": "https://ubuntu.com/security/CVE-2026-64567", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: reject free space cache with more entries than pages When loading a v1 free space cache, __load_free_space_cache() takes num_entries and num_bitmaps straight from the on-disk btrfs_free_space_header. That header is stored in the tree_root under a key with type 0, which the tree-checker has no case for, so neither count is validated before the load trusts it. The load loops num_entries times and maps the next page whenever the current one runs out, going through io_ctl_check_crc() -> io_ctl_map_page(), which does io_ctl->pages[io_ctl->index++]. But pages[] is allocated in io_ctl_init() from the cache inode's i_size, not from num_entries: \tnum_pages = DIV_ROUND_UP(i_size_read(inode), PAGE_SIZE); \tio_ctl->pages = kcalloc(num_pages, sizeof(struct page *), GFP_NOFS); So if num_entries claims more records than the pages can hold, io_ctl->index runs off the end of pages[]. The write side never hits this because io_ctl_add_entry() and io_ctl_add_bitmap() both stop once io_ctl->index >= io_ctl->num_pages; the read side just never had the same check. To trigger it, take a clean cache (num_entries = here), set num_entries in the header to 0x10000, and fix up the leaf checksum so it still passes the tree-checker. The cache inode has i_size = 65536, so num_pages is 16 and pages[] is a 16-pointer (kmalloc-128) array. The load now tries to read 65536 entries, io_ctl->index walks up to 16, and pages[16] is read past the array: BUG: KASAN: slab-out-of-bounds in io_ctl_check_crc (fs/btrfs/free-space-cache.c:420 fs/btrfs/free-space-cache.c:565) Read of size 8 at addr ffff88800c833a80 by task kworker/u8:3/58 io_ctl_check_crc (fs/btrfs/free-space-cache.c:420 fs/btrfs/free-space-cache.c:565) __load_free_space_cache (fs/btrfs/free-space-cache.c:655 fs/btrfs/free-space-cache.c:820) load_free_space_cache (fs/btrfs/free-space-cache.c:1017) caching_thread (fs/btrfs/block-group.c:880) btrfs_work_helper (fs/btrfs/async-thread.c:312) process_one_work worker_thread kthread ret_from_fork free-space-cache.c:420 is io_ctl_map_page(), inlined into io_ctl_check_crc() at line 565, which is why that is the frame KASAN names. The out-of-bounds slot is then treated as a struct page and handed to crc32c(), so the bad read turns into a GP fault. Add the missing check to io_ctl_check_crc(), which is where both the entry loop and the bitmap loop end up. When num_entries is too large the load now fails like any corrupt cache: __load_free_space_cache() drops it and rebuilds the free space from the extent tree, so a valid cache is never rejected.", "cve_priority": "high", "cve_public_date": "2026-08-05 08:16:00 UTC" }, { "cve": "CVE-2026-68425", "url": "https://ubuntu.com/security/CVE-2026-68425", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: IB/mad: Drop unmatched RMPP responses before reassembly Kernel-handled RMPP receive processing starts reassembly for active DATA responses before the response is matched to an outstanding send. The normal match happens later, after ib_process_rmpp_recv_wc() has either assembled a complete message or consumed the segment. That ordering lets an unsolicited response that routes to a kernel RMPP agent by the high TID bits allocate or extend RMPP receive state before the full TID and source address are checked against a real request. A reordered burst can therefore reach the receive-side insertion path even though the response would not match any send. For kernel-handled RMPP DATA responses, require the existing ib_find_send_mad() match before entering RMPP reassembly. The matcher already checks the full TID, management class and source address/GID against the agent wait, backlog and in-flight send lists. If there is no match, drop the response without creating RMPP state. This leaves the RMPP window behavior unchanged and only rejects responses that have no corresponding request.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64565", "url": "https://ubuntu.com/security/CVE-2026-64565", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: ims-pcu - fix heap-buffer-overflow in ims_pcu_process_data() The `ims_pcu_process_data()` processes incoming URB data byte by byte. However, it fails to check if the `read_pos` index exceeds IMS_PCU_BUF_SIZE. If a malicious USB device sends a packet larger than IMS_PCU_BUF_SIZE, `read_pos` will increment indefinitely. Moreover, since `read_pos` is located immediately after `read_buf`, the attacker can overwrite `read_pos` itself to arbitrarily control the index. This manipulated `read_pos` is subsequently used in `ims_pcu_handle_response()` to copy data into `cmd_buf`, leading to a heap buffer overflow. Specifically, an attacker can overwrite the `cmd_done.wait.head` located at offset 136 relative to `cmd_buf` in the `ims_pcu_handle_response()`. Consequently, when the driver calls `complete(&pcu->cmd_done)`, it triggers a control flow hijack by using the manipulated pointer. Fix this by adding a bounds check for `read_pos` before writing to `read_buf`. If the packet is too long, discard it, log a warning, and reset the parser state. [dtor: factor out resetting packet state, reset checksum as well]", "cve_priority": "medium", "cve_public_date": "2026-08-04 07:16:00 UTC" }, { "cve": "CVE-2026-68427", "url": "https://ubuntu.com/security/CVE-2026-68427", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpu: host1x: Fix use-after-free in host1x_bo_clear_cached_mappings __host1x_bo_unpin() drops the last reference to the mapping and frees it, so we can't dereference mapping afterwards. The cache itself outlives the mapping, so use the cache local variable instead.", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-72146", "url": "https://ubuntu.com/security/CVE-2026-72146", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dmaengine: sh: rz-dmac: Move interrupt request after everything is set up Once the interrupt is requested, the interrupt handler may run immediately. Since the IRQ handler can access channel->ch_base, which is initialized only after requesting the IRQ, this may lead to invalid memory access. Likewise, the IRQ thread may access uninitialized data (the ld_free, ld_queue, and ld_active lists), which may also lead to issues. Request the interrupts only after everything is set up. To keep the error path simpler, use dmam_alloc_coherent() instead of dma_alloc_coherent().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72124", "url": "https://ubuntu.com/security/CVE-2026-72124", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: isotp: serialize TX state transitions under so->rx_lock The TX state machine (so->tx.state) is driven from three contexts: sendmsg() claiming and progressing a transfer, the RX path consuming Flow Control/echo frames, and two hrtimers timing out a stalled transfer. Mixing a lock-free cmpxchg() claim in sendmsg() with hrtimer_cancel() calls made under so->rx_lock elsewhere left windows where a frame or timer callback could act on a state that had already moved on, corrupting an unrelated transfer. so->rx_lock now covers the full lifecycle of a TX claim: sendmsg() takes it to check so->tx.state is ISOTP_IDLE, switch it to ISOTP_SENDING, bump so->tx_gen and drain the previous transfer's timers - all as one critical section. isotp_rcv_fc()/isotp_rcv_cf() already run under this lock via isotp_rcv(), and isotp_rcv_echo() now takes it itself, so none of them can ever observe a transfer mid-claim. This also means a transfer can no longer be handed to sendmsg()'s cleanup paths (signal or send error) while another thread is concurrently claiming or finishing it, so those paths can cancel timers and reset the state unconditionally. isotp_release() claims the socket the same way, so a racing sendmsg() sees a consistent ISOTP_SHUTDOWN and skips arming its timer or sending. Only the hrtimer callbacks stay outside so->rx_lock, since they run under so->rx_lock's cancellation elsewhere and taking it themselves would deadlock. so->tx_gen lets them recognize whether the transfer they timed out is still the one currently active, so they don't report an error against a transfer that has since completed or been superseded.", "cve_priority": "high", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72125", "url": "https://ubuntu.com/security/CVE-2026-72125", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: isotp: fix use-after-free race with concurrent NETDEV_UNREGISTER isotp_release() looked up the bound network device via dev_get_by_index() using the stored ifindex. During device unregistration the device is unlisted from the ifindex hash before the NETDEV_UNREGISTER notifier chain runs, so a concurrent isotp_release() could find no device, skip can_rx_unregister() entirely, and still proceed to free the socket. Since isotp_release() had already removed itself from the isotp notifier list at that point, isotp_notify() would never get a chance to clean up either, leaving a stale CAN filter that keeps pointing at the freed socket. Fix this the same way raw.c already does: hold a tracked reference to the bound net_device in the socket (so->dev/so->dev_tracker) from bind() onward instead of re-resolving it from the ifindex, and serialize bind()/release() with rtnl_lock() so that so->dev is always consistent with what the NETDEV_UNREGISTER notifier sees. so->dev stays valid regardless of ifindex-hash unlisting, and is only ever cleared by whichever of isotp_release()/isotp_notify() gets there first, so the filter is always removed exactly once. isotp_bind() now rejects a (re)bind with -EAGAIN while so->[tx|rx].state isn't ISOTP_IDLE yet, so a timer left running by a prior NETDEV_UNREGISTER can't act on a newly bound so->ifindex. Both checks share the same lock_sock() section, so there is no window in which a concurrent isotp_notify() clearing so->bound could be missed.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72115", "url": "https://ubuntu.com/security/CVE-2026-72115", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: track a single source interface for ANYDEV timeout/throttle ops An ANYDEV rx op (ifindex == 0) with an active RX timeout and/or throttle timer has no defined semantics when matching frames arrive from several interfaces: bcm_rx_handler() can run concurrently for the same op on different CPUs, racing hrtimer_cancel()/ bcm_rx_starttimer() against bcm_rx_timeout_handler() and causing spurious RX_TIMEOUT notifications and last_frames corruption. The same concurrency lets throttled multiplex frames from different interfaces clobber the single rx_ifindex/rx_stamp fields shared by the op. Add op->if_detected to track the first interface that delivers a matching frame while a timeout/throttle timer is configured, and reject frames from any other interface for that op. The claim is decided in bcm_rx_handler() before hrtimer_cancel() touches op->timer, so a rejected frame can never disturb the claimed interface's watchdog. RTR-mode ops are excluded via RX_RTR_FRAME, independent of kt_ival1/kt_ival2, since those may briefly hold a stale value from an earlier non-RTR configuration. The claim is released in bcm_notify() on NETDEV_UNREGISTER and in bcm_rx_setup() when SETTIMER reconfigures the timer values. A (re-)claim is only possible on CAN devices in NETREG_REGISTERED dev->reg_state to cover the release in bcm_notify() where reg_state becomes NETREG_UNREGISTERING until synchronize_net().", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72117", "url": "https://ubuntu.com/security/CVE-2026-72117", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: fix data race on rx_stamp/rx_ifindex in bcm_rx_handler() For an rx op subscribed on all interfaces (ifindex == 0), the same op is registered once in the shared per-netns wildcard filter list, so bcm_rx_handler() can run concurrently on different CPUs for frames arriving on different net devices. op->rx_stamp and op->rx_ifindex were written before bcm_rx_update_lock was taken, allowing concurrent writers to race each other - including a torn store of the 64-bit rx_stamp on 32-bit platforms. Beyond a torn store bcm_send_to_user() must report the timestamp/ifindex of the very same frame whose content it is delivering. So the assignment is placed in the same unbroken bcm_rx_update_lock section as the content comparison. As a side effect, the RTR-request frame feature (which never reach bcm_send_to_user()) no longer updates rx_stamp/rx_ifindex, since only the notification path needs them.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72116", "url": "https://ubuntu.com/security/CVE-2026-72116", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: fix stale rx/tx ops after device removal RX: an RX_SETUP update(!) for an existing op skipped can_rx_register() unconditionally, even when a concurrent NETDEV_UNREGISTER had already torn down its registration (op->rx_reg_dev == NULL). This silently did not re-enable frame delivery for that updated filter. bcm_rx_setup() now re-registers in that case, while leaving rx_ops with ifindex = 0 (all CAN devices) which never carry a tracked rx_reg_dev registered as-is. TX: bcm_notify() only handled bo->rx_ops on NETDEV_UNREGISTER, leaving tx_ops with an active cyclic transmission re-arming its hrtimer indefinitely to execute bcm_tx_timeout_handler(). Cancelling the hrtimer prevents the runaway timer and any injection into a later reused ifindex, since nothing else calls bcm_can_tx() for the op until an explicit TX_SETUP update re-arms it. Unlike bcm_rx_unreg(), which clears the tracked rx_reg_dev for rx_ops, the ifindex is intentionally left unchanged for tx_ops. bcm_tx_setup() always rejects ifindex 0, so clearing it would strand the op: neither a later TX_SETUP (bcm_find_op()) nor TX_DELETE (bcm_delete_tx_op()) could ever find it again, since both require an exact ifindex match.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72113", "url": "https://ubuntu.com/security/CVE-2026-72113", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: add missing device refcount for CAN filter removal sashiko-bot remarked a problem with a concurrent device unregistration in isotp.c which also is present in the bcm.c code. A former fix for raw.c commit c275a176e4b6 (\"can: raw: add missing refcount for memory leak fix\") introduced a netdevice_tracker which solves the issue for bcm.c too. bcm_release(), bcm_delete_rx_op() and bcm_notifier() relied on dev_get_by_index(ifindex) to re-find the device for an rx_op before unregistering its filter. If a concurrent NETDEV_UNREGISTER has already unlisted the device from the ifindex table, that lookup fails and can_rx_unregister() is silently skipped, leaving a stale CAN filter pointing at the soon-to-be-freed bcm_op/socket. Hold a netdev_hold()/netdev_put() tracked reference on op->rx_reg_dev from the moment the rx filter is registered in bcm_rx_setup() until it is unregistered in bcm_rx_unreg(), and use that reference directly in bcm_release() and bcm_delete_rx_op() instead of re-looking the device up by ifindex.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72114", "url": "https://ubuntu.com/security/CVE-2026-72114", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: validate frame length in bcm_rx_setup() for RTR replies bcm_tx_setup() validates cf->len against the CAN/CAN FD DLC limits before installing frames for TX_SETUP, but bcm_rx_setup() never did the same for the RTR-reply frame configured via RX_SETUP with RX_RTR_FRAME.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72119", "url": "https://ubuntu.com/security/CVE-2026-72119", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: extend bcm_tx_lock usage for data and timer updates Stage new CAN frame content for an existing tx op into a kmalloc()'d buffer and validate it there, mirroring the approach already used in bcm_rx_setup(). Only copy the validated data into op->frames while holding op->bcm_tx_lock, so bcm_can_tx() and bcm_tx_timeout_handler() can no longer observe a partially updated or unvalidated frame. Add a missing error path for memcpy_from_msg() when copying CAN frame data from userspace. Also move the kt_ival1/kt_ival2/ival1/ival2 updates in bcm_tx_setup() under op->bcm_tx_lock, and read kt_ival1/kt_ival2/count under the same lock in bcm_tx_set_expiry() and bcm_tx_timeout_handler(), closing the torn 64-bit ktime_t read on 32-bit platforms.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72118", "url": "https://ubuntu.com/security/CVE-2026-72118", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: fix CAN frame rx/tx statistics KCSAN detected a data race within the bcm_rx_handler() when two CAN frames have been simultaneously received and processed in a single rx op by two different CPUs. Use atomic operations with (signed) long data types to access the statistics in the hot path to fix the KCSAN complaint. Additionally simplify the update and check of statistics overflow by using the atomic operations in separate bcm_update_[rx|tx]_stats() functions. The rx variant runs under bcm_rx_update_lock to prevent races when resetting the two rx counters; the tx variant runs under bcm_tx_lock and only needs to guard its own counter's overflow. As the rx path resets its values already at LONG_MAX / 100, there is no conflict between the two locking domains (bcm_rx_update_lock vs. bcm_tx_lock) even for ops that use both paths. The rx statistics update and the frames_filtered update in bcm_rx_changed() were previously performed in two separate bcm_rx_update_lock sections. For an rx op subscribed on all interfaces (ifindex == 0), bcm_rx_handler() can run concurrently on different CPUs, so a counter reset by one CPU between these two sections could leave frames_filtered larger than frames_abs on another CPU, producing a bogus (even negative) reduction percentage in procfs. Update the statistics in the same critical section as bcm_rx_changed() to close this gap, which also removes the now unneeded extra lock/unlock pair around the traffic_flags calculation.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-72121", "url": "https://ubuntu.com/security/CVE-2026-72121", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: add locking when updating filter and timer values KCSAN detected a simultaneous access to timer values that can be overwritten in bcm_rx_setup() when updating timer and filter content while bcm_rx_handler(), bcm_rx_timeout_handler() or bcm_rx_thr_handler() run concurrently on incoming CAN traffic. Protect the timer (ival1/ival2/kt_ival1/kt_ival2/kt_lastmsg) and filter (nframes/flags/frames/last_frames) updates in bcm_rx_setup() with a new per-op bcm_rx_update_lock, taken with the matching scope in the RX handlers. memcpy_from_msg() is staged into a temporary buffer before the lock is taken, since it can sleep and must not run under a spinlock. hrtimer_cancel() is always called without bcm_rx_update_lock held, since bcm_rx_timeout_handler()/bcm_rx_thr_handler() take the same lock and a running callback would otherwise deadlock against the canceller. Also close a related race: bcm_rx_setup() cleared the RTR flag in the stored reply frame's can_id as a separate, unprotected step after the frame content was already installed, so a concurrent bcm_rx_handler() could transmit a stale reply with CAN_RTR_FLAG still set. Fold that normalization into the initial frame preparation instead (on the staged buffer for updates, directly on op->frames pre-registration for new ops), so the installed frame is always atomically self-consistent. bcm_rx_handler()'s RX_RTR_FRAME check now takes a lock-protected snapshot of op->flags before deciding whether to call bcm_can_tx(), but does not hold the lock across that call. Also take a lock-protected snapshot of the currframe in bcm_can_tx() to avoid partly overwrites by content updates in bcm_tx_setup(). Finally check if a TX_RESET_MULTI_IDX/SETTIMER might have reset op->currframe between the two locked sections in bcm_can_tx(). Omit calling hrtimer_forward() with zero interval in bcm_rx_thr_handler(). kt_ival2 may have been concurrently cleared by bcm_rx_setup() before it cancels this timer, so check kt_ival2 inside the bcm_rx_update_lock.", "cve_priority": "medium", "cve_public_date": "2026-08-15 06:21:00 UTC" }, { "cve": "CVE-2026-68428", "url": "https://ubuntu.com/security/CVE-2026-68428", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86/mmu: Fix use-after-free on vendor module reload mmu_destroy_caches() destroys pte_list_desc_cache and mmu_page_header_cache, but leaves both pointers unchanged. The pointers live in kvm.ko, and therefore survive when a vendor module is unloaded while kvm.ko remains loaded. If creation of pte_list_desc_cache fails during a subsequent vendor module load, its assignment sets pte_list_desc_cache to NULL and the error path calls mmu_destroy_caches(). mmu_page_header_cache still points to the cache destroyed during the preceding vendor module unload. Passing that stale pointer to kmem_cache_destroy() causes a slab use-after-free. Reproduce the issue on a v7.1.3 kernel with CONFIG_KASAN=y, CONFIG_KASAN_GENERIC=y, CONFIG_KVM=m, and CONFIG_KVM_INTEL=m. A one-shot test hook forces pte_list_desc_cache to NULL on the second invocation of kvm_mmu_vendor_module_init(): 1. Load kvm.ko and kvm-intel.ko, creating both caches. 2. Unload only kvm_intel, leaving kvm.ko loaded. 3. Reload kvm_intel and force initialization through the -ENOMEM path. KASAN reports: BUG: KASAN: slab-use-after-free in kvm_mmu_vendor_module_init+0x5b/0x170 [kvm] ... kmem_cache_destroy+0x21/0x1d0 kvm_mmu_vendor_module_init+0x5b/0x170 [kvm] ... Allocated by task 16817: __kmem_cache_create_args+0x12c/0x3b0 __kmem_cache_create.constprop.0+0xb6/0xf0 [kvm] kvm_mmu_vendor_module_init+0x13b/0x170 [kvm] ... Freed by task 16820: kmem_cache_destroy+0x117/0x1d0 kvm_mmu_vendor_module_exit+0x21/0x30 [kvm] Clear both pointers immediately after destroying their caches so that the stored state reflects the caches' lifetime and repeated cleanup is safe. With the fix applied, the same injected vendor module reload fails with -ENOMEM as expected and produces no KASAN report.", "cve_priority": "medium", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2026-64562", "url": "https://ubuntu.com/security/CVE-2026-64562", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: nVMX: Hide shadow VMCS right after VMCLEAR free_nested() frees the shadow VMCS while vmcs01 still points to it. But because it is asynchronous with respect to loaded_vmcs_clear(), the vCPU might migrate before the pointer is cleared and __loaded_vmcs_clear() may then execute VMCLEAR. The VMCS needs to stay attached until its explicit VMCLEAR completes, but then it can be hidden and the page safely freed.", "cve_priority": "high", "cve_public_date": "2026-08-04 07:16:00 UTC" }, { "cve": "CVE-2026-64561", "url": "https://ubuntu.com/security/CVE-2026-64561", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Check for invalid/obsolete root *after* making MMU pages available Check for a \"stale\" page fault, i.e. for an invalid and/or obsolete root, after making MMU pages available for the shadow MMU. If reclaiming shadow pages zaps an in-use root, i.e. marks it invalid, then KVM will attempt to map memory into an invalid root. On its own, populating an invalid root is \"fine\", but because child shadow pages inherit their parent's role, any children created during the map/fetch will be created as invalid pages, thus violating KVM's invariant that invalid pages are never on the list of active MMU pages. Note, the underlying flaw has existed since KVM first started tracking invalid roots in 2008 (commit 2e53d63acba7, \"KVM: MMU: ignore zapped root pagetables\"), but the true badness only came along in 2020 (Linux 5.9) with the invariant that invalid shadow pages can't be on the list of active pages. Note #2, inheriting role.invalid when creating child shadow pages is also far from ideal; that flaw will be addressed separately.", "cve_priority": "medium", "cve_public_date": "2026-08-04 07:16:00 UTC" }, { "cve": "CVE-2026-53090", "url": "https://ubuntu.com/security/CVE-2026-53090", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix ld_{abs,ind} failure path analysis in subprogs Usage of ld_{abs,ind} instructions got extended into subprogs some time ago via commit 09b28d76eac4 (\"bpf: Add abnormal return checks.\"). These are only allowed in subprograms when the latter are BTF annotated and have scalar return types. The code generator in bpf_gen_ld_abs() has an abnormal exit path (r0=0 + exit) from legacy cBPF times. While the enforcement is on scalar return types, the verifier must also simulate the path of abnormal exit if the packet data load via ld_{abs,ind} failed. This is currently not the case. Fix it by having the verifier simulate both success and failure paths, and extend it in similar ways as we do for tail calls. The success path (r0=unknown, continue to next insn) is pushed onto stack for later validation and the r0=0 and return to the caller is done on the fall-through side.", "cve_priority": "high", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-64564", "url": "https://ubuntu.com/security/CVE-2026-64564", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: don't free the ASCONF's own transport in DEL-IP processing sctp_process_asconf() caches the transport the ASCONF chunk is processed against in asconf->transport (== chunk->transport, set once in sctp_rcv()). For an ASCONF located through its Address Parameter by __sctp_rcv_asconf_lookup(), that cached transport corresponds to the Address Parameter, which need not be the packet's source address. sctp_process_asconf_param() rejects a DEL-IP for the packet source address (ADDIP D8, SCTP_ERROR_DEL_SRC_IP), but nothing protects asconf->transport. A single ASCONF can therefore carry, in order: [Address Parameter L] [DEL-IP L] [DEL-IP 0.0.0.0] where L differs from the source. The DEL-IP for L passes the D8 check and calls sctp_assoc_rm_peer() on the transport that asconf->transport still points at, freeing it (RCU-deferred). The following wildcard DEL-IP then reuses the now-dangling asconf->transport in sctp_assoc_set_primary() and sctp_assoc_del_nonprimary_peers(): set_primary() dereferences the freed transport (->ipaddr, ->state) and plants the dangling pointer into asoc->peer.primary_path / active_path, and del_nonprimary_peers(), keeping only the pointer that is no longer on the list, removes every real transport, leaving the association with a transport_count of 0 and primary_path/active_path pointing at freed memory. Reject a DEL-IP that targets the transport the ASCONF is being processed against, mirroring the existing source-address guard, so the wildcard branch can never reuse a freed transport.", "cve_priority": "critical", "cve_public_date": "2026-08-04 07:16:00 UTC" }, { "cve": "CVE-2026-68399", "url": "https://ubuntu.com/security/CVE-2026-68399", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix UAF in sock clone early bailouts Similar to recent commit 9b51a6155d14 (\"bpf,fork: wipe ->bpf_storage before bailouts that access it\"), sk_clone() performs an initial shallow copy of the socket field ->sk_bpf_storage via sock_copy() for the cloned socket newsk. If sk_clone() bails out early (e.g. if sk_filter_charge() fails) prior to calling bpf_sk_storage_clone(), newsk->sk_bpf_storage still points to the parent socket's BPF local storage. When newsk is subsequently freed via sk_free(), the deallocation path (__sk_destruct() -> bpf_sk_storage_free()) destroys the parent socket's BPF local storage, leading to a use-after-free (UAF) on the parent socket. Fix this by resetting newsk->sk_bpf_storage to NULL immediately after sock_copy() in sk_clone(), and remove the now redundant initialization from bpf_sk_storage_clone().", "cve_priority": "high", "cve_public_date": "2026-08-10 13:20:00 UTC" }, { "cve": "CVE-2025-38563", "url": "https://ubuntu.com/security/CVE-2025-38563", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf/core: Prevent VMA split of buffer mappings The perf mmap code is careful about mmap()'ing the user page with the ringbuffer and additionally the auxiliary buffer, when the event supports it. Once the first mapping is established, subsequent mapping have to use the same offset and the same size in both cases. The reference counting for the ringbuffer and the auxiliary buffer depends on this being correct. Though perf does not prevent that a related mapping is split via mmap(2), munmap(2) or mremap(2). A split of a VMA results in perf_mmap_open() calls, which take reference counts, but then the subsequent perf_mmap_close() calls are not longer fulfilling the offset and size checks. This leads to reference count leaks. As perf already has the requirement for subsequent mappings to match the initial mapping, the obvious consequence is that VMA splits, caused by resizing of a mapping or partial unmapping, have to be prevented. Implement the vm_operations_struct::may_split() callback and return unconditionally -EINVAL. That ensures that the mapping offsets and sizes cannot be changed after the fact. Remapping to a different fixed address with the same size is still possible as it takes the references for the new mapping and drops those of the old mapping.", "cve_priority": "high", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2025-38565", "url": "https://ubuntu.com/security/CVE-2025-38565", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: perf/core: Exit early on perf_mmap() fail When perf_mmap() fails to allocate a buffer, it still invokes the event_mapped() callback of the related event. On X86 this might increase the perf_rdpmc_allowed reference counter. But nothing undoes this as perf_mmap_close() is never called in this case, which causes another reference count leak. Return early on failure to prevent that.", "cve_priority": "low", "cve_public_date": "2025-08-19 17:15:00 UTC" }, { "cve": "CVE-2025-38187", "url": "https://ubuntu.com/security/CVE-2025-38187", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/nouveau: fix a use-after-free in r535_gsp_rpc_push() The RPC container is released after being passed to r535_gsp_rpc_send(). When sending the initial fragment of a large RPC and passing the caller's RPC container, the container will be freed prematurely. Subsequent attempts to send remaining fragments will therefore result in a use-after-free. Allocate a temporary RPC container for holding the initial fragment of a large RPC when sending. Free the caller's container when all fragments are successfully sent. [ Rebase onto Blackwell changes. - Danilo ]", "cve_priority": "high", "cve_public_date": "2025-07-04 14:15:00 UTC" }, { "cve": "CVE-2025-38069", "url": "https://ubuntu.com/security/CVE-2025-38069", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: endpoint: pci-epf-test: Fix double free that causes kernel to oops Fix a kernel oops found while testing the stm32_pcie Endpoint driver with handling of PERST# deassertion: During EP initialization, pci_epf_test_alloc_space() allocates all BARs, which are further freed if epc_set_bar() fails (for instance, due to no free inbound window). However, when pci_epc_set_bar() fails, the error path: pci_epc_set_bar() -> pci_epf_free_space() does not clear the previous assignment to epf_test->reg[bar]. Then, if the host reboots, the PERST# deassertion restarts the BAR allocation sequence with the same allocation failure (no free inbound window), creating a double free situation since epf_test->reg[bar] was deallocated and is still non-NULL. Thus, make sure that pci_epf_alloc_space() and pci_epf_free_space() invocations are symmetric, and as such, set epf_test->reg[bar] to NULL when memory is freed. [kwilczynski: commit log]", "cve_priority": "low", "cve_public_date": "2025-06-18 10:15:00 UTC" }, { "cve": "CVE-2025-40014", "url": "https://ubuntu.com/security/CVE-2025-40014", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: objtool, spi: amd: Fix out-of-bounds stack access in amd_set_spi_freq() If speed_hz < AMD_SPI_MIN_HZ, amd_set_spi_freq() iterates over the entire amd_spi_freq array without breaking out early, causing 'i' to go beyond the array bounds. Fix that by stopping the loop when it gets to the last entry, so the low speed_hz value gets clamped up to AMD_SPI_MIN_HZ. Fixes the following warning with an UBSAN kernel: drivers/spi/spi-amd.o: error: objtool: amd_set_spi_freq() falls through to next function amd_spi_set_opcode()", "cve_priority": "low", "cve_public_date": "2025-04-18 07:15:00 UTC" }, { "cve": "CVE-2025-21985", "url": "https://ubuntu.com/security/CVE-2025-21985", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix out-of-bound accesses [WHAT & HOW] hpo_stream_to_link_encoder_mapping has size MAX_HPO_DP2_ENCODERS(=4), but location can have size up to 6. As a result, it is necessary to check location against MAX_HPO_DP2_ENCODERS. Similiarly, disp_cfg_stream_location can be used as an array index which should be 0..5, so the ASSERT's conditions should be less without equal.", "cve_priority": "medium", "cve_public_date": "2025-04-01 16:15:00 UTC" }, { "cve": "CVE-2024-56552", "url": "https://ubuntu.com/security/CVE-2024-56552", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc_submit: fix race around suspend_pending Currently in some testcases we can trigger: xe 0000:03:00.0: [drm] Assertion `exec_queue_destroyed(q)` failed! .... WARNING: CPU: 18 PID: 2640 at drivers/gpu/drm/xe/xe_guc_submit.c:1826 xe_guc_sched_done_handler+0xa54/0xef0 [xe] xe 0000:03:00.0: [drm] *ERROR* GT1: DEREGISTER_DONE: Unexpected engine state 0x00a1, guc_id=57 Looking at a snippet of corresponding ftrace for this GuC id we can see: 162.673311: xe_sched_msg_add: dev=0000:03:00.0, gt=1 guc_id=57, opcode=3 162.673317: xe_sched_msg_recv: dev=0000:03:00.0, gt=1 guc_id=57, opcode=3 162.673319: xe_exec_queue_scheduling_disable: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0x29, flags=0x0 162.674089: xe_exec_queue_kill: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0x29, flags=0x0 162.674108: xe_exec_queue_close: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0xa9, flags=0x0 162.674488: xe_exec_queue_scheduling_done: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0xa9, flags=0x0 162.678452: xe_exec_queue_deregister: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0xa1, flags=0x0 It looks like we try to suspend the queue (opcode=3), setting suspend_pending and triggering a disable_scheduling. The user then closes the queue. However the close will also forcefully signal the suspend fence after killing the queue, later when the G2H response for disable_scheduling comes back we have now cleared suspend_pending when signalling the suspend fence, so the disable_scheduling now incorrectly tries to also deregister the queue. This leads to warnings since the queue has yet to even be marked for destruction. We also seem to trigger errors later with trying to double unregister the same queue. To fix this tweak the ordering when handling the response to ensure we don't race with a disable_scheduling that didn't actually intend to perform an unregister. The destruction path should now also correctly wait for any pending_disable before marking as destroyed. (cherry picked from commit f161809b362f027b6d72bd998e47f8f0bad60a2e)", "cve_priority": "medium", "cve_public_date": "2024-12-27 15:15:00 UTC" }, { "cve": "CVE-2025-21687", "url": "https://ubuntu.com/security/CVE-2025-21687", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vfio/platform: check the bounds of read/write syscalls count and offset are passed from user space and not checked, only offset is capped to 40 bits, which can be used to read/write out of bounds of the device.", "cve_priority": "medium", "cve_public_date": "2025-02-10 16:15:00 UTC" }, { "cve": "CVE-2026-64560", "url": "https://ubuntu.com/security/CVE-2026-64560", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: posix-cpu-timers: Prevent UAF caused by non-leader exec() race Wongi and Jungwoo decoded and reported a non-leader exec() related race which can result in an UAF: sys_timer_delete()\t\t\texec() posix_cpu_timer_del() // Observes old leader p = pid_task(pid, pid_type);\t\tde_thread() \t\t\t\t\t switch_leader(); \t\t\t\t\t release_task(old_leader) \t\t\t\t\t __exit_signal(old_leader) \t\t\t\t\t sighand = lock(old_leader, sighand); \t\t\t\t\t posix_cpu_timers*_exit(); sighand = lock_task_sighand(p)\t unhash_task(old_leader); sh = lock(p, sighand)\t \t old_leader->sighand = NULL; \t\t\t\t\t unlock(sighand); (p->sighand == NULL) \tunlock(sh) \treturn NULL; // Returns without action if(!sighand) return 0; free_posix_timer(); This is \"harmless\" unless the deleted timer was armed and enqueued in p->signal because on exec() a TGID targeted timer is inherited. As sys_timer_delete() freed the underlying posix timer object run_posix_cpu_timers() or any timerqueue related add/delete operations on other timers will access the freed object's timerqueue node, which results in an UAF. There is a similar problem vs. posix_cpu_timer_set(). For regular posix timers it just transiently returns -ESRCH to user space, but for the use case in do_cpu_nanosleep() it's the same UAF just that the k_itimer is allocated on the stack. Also posix_cpu_timer_rearm() fails to rearm the timer, which means it stops to expire. While debating solutions Frederic pointed out another problem: posix_cpu_timer_del(tmr) \t\t\t\t\t__exit_signal(p) \t\t\t\t\t posix_cpu_timers*_exit(p); \t\t\t\t\t unhash_task(p); \t\t\t\t\t p->sighand = NULL; sh = lock_task_sighand(p) sighand = p->sighand; \tif (!sighand) \t return NULL; \tlock(sighand); if (!sh) \tWARN_ON_ONCE(timer_queued(tmr)); On weakly ordered architectures it is not guaranteed that posix_cpu_timer_del() will observe the stores in posix_cpu_timers*_exit() when p->sighand is observed as NULL, which means the WARN() can be a false positive. Solve these issues by: 1) Changing the store in __exit_signal() to smp_store_release(). 2) Adding a smp_acquire__after_ctrl_dep() into the !sighand path of lock_task_sighand(). 3) Creating a helper function for looking up the task and locking sighand which does not return when sighand == NULL. Instead it retries the task lookup and only if that fails it gives up. 4) Using that helper in the three affected functions. #1/#2 ensures that the reader side which observes sighand == NULL also observes all preceeding stores, i.e. the stores in posix_cpu_timers*_exit() and the ones in unhash_task(). #3 ensures that the above described non-leader exec() situation is handled gracefully. When the task lookup returns the old leader, but sighand == NULL then it retries. In the non-leader exec() case the subsequent task lookup will observe the new leader due to #1/#2. In normal exit() scenarios the subsequent lookup fails. When the task lookup fails, the function also checks whether the timer is still enqueued and issues a warning if that's the case. Unfortunately there is nothing which can be done about it, but as the task is already not longer visible the timer should not be accessed anymore. This check also requires memory ordering, which is not provided when the first lookup fails. To achieve that the check is preceeded by a smp_rmb() which pairs with the smp_wmb() in write_seqlock() in __exit_signal(). That ensures that the stores in posix_cpu_timers*_exit() are visible. The history of the non-leader exec() issue goes back to the early days of posix CPU timers, which stored a pointer to the group leader task in the timer. That obviously fails when a non-leader exec() switches the leader. commit e0a70217107e (\"posix-cpu-timers: workaround to suppress the problems with mt exec\") added a temporary workaround for that in 2010 which surv ---truncated---", "cve_priority": "medium", "cve_public_date": "2026-07-29 17:16:00 UTC" }, { "cve": "CVE-2026-53365", "url": "https://ubuntu.com/security/CVE-2026-53365", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: fix zerocopy completion for multi-skb sends When a large message is fragmented into multiple skbs, the zerocopy uarg is only allocated and attached to the last skb in the loop. Non-final skbs carry pinned user pages with no completion tracking, so the kernel has no way to notify userspace when those pages are safe to reuse. If the loop breaks early the uarg is never allocated at all, leaking pinned pages with no completion notification. Fix this by following the approach used by TCP: allocate the zerocopy uarg (if not provided by the caller) before the send loop and attach it to every skb via skb_zcopy_set(), which takes a reference per skb. Each skb's completion properly decrements the refcount, and the notification only fires after the last skb is freed. On failure, if no data was sent, the uarg is cleanly aborted via net_zcopy_put_abort(). This issue was initially discovered by sashiko while reviewing commit 1cb36e252211 (\"vsock/virtio: fix MSG_ZEROCOPY pinned-pages accounting\") but was pre-existing.", "cve_priority": "high", "cve_public_date": "2026-07-13 18:16:00 UTC" }, { "cve": "CVE-2025-37964", "url": "https://ubuntu.com/security/CVE-2025-37964", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/mm: Eliminate window where TLB flushes may be inadvertently skipped tl;dr: There is a window in the mm switching code where the new CR3 is set and the CPU should be getting TLB flushes for the new mm. But should_flush_tlb() has a bug and suppresses the flush. Fix it by widening the window where should_flush_tlb() sends an IPI. Long Version: === History === There were a few things leading up to this. First, updating mm_cpumask() was observed to be too expensive, so it was made lazier. But being lazy caused too many unnecessary IPIs to CPUs due to the now-lazy mm_cpumask(). So code was added to cull mm_cpumask() periodically[2]. But that culling was a bit too aggressive and skipped sending TLB flushes to CPUs that need them. So here we are again. === Problem === The too-aggressive code in should_flush_tlb() strikes in this window: \t// Turn on IPIs for this CPU/mm combination, but only \t// if should_flush_tlb() agrees: \tcpumask_set_cpu(cpu, mm_cpumask(next)); \tnext_tlb_gen = atomic64_read(&next->context.tlb_gen); \tchoose_new_asid(next, next_tlb_gen, &new_asid, &need_flush); \tload_new_mm_cr3(need_flush); \t// ^ After 'need_flush' is set to false, IPIs *MUST* \t// be sent to this CPU and not be ignored. this_cpu_write(cpu_tlbstate.loaded_mm, next); \t// ^ Not until this point does should_flush_tlb() \t// become true! should_flush_tlb() will suppress TLB flushes between load_new_mm_cr3() and writing to 'loaded_mm', which is a window where they should not be suppressed. Whoops. === Solution === Thankfully, the fuzzy \"just about to write CR3\" window is already marked with loaded_mm==LOADED_MM_SWITCHING. Simply checking for that state in should_flush_tlb() is sufficient to ensure that the CPU is targeted with an IPI. This will cause more TLB flush IPIs. But the window is relatively small and I do not expect this to cause any kind of measurable performance impact. Update the comment where LOADED_MM_SWITCHING is written since it grew yet another user. Peter Z also raised a concern that should_flush_tlb() might not observe 'loaded_mm' and 'is_lazy' in the same order that switch_mm_irqs_off() writes them. Add a barrier to ensure that they are observed in the order they are written.", "cve_priority": "high", "cve_public_date": "2025-05-20 16:15:00 UTC" }, { "cve": "CVE-2026-53389", "url": "https://ubuntu.com/security/CVE-2026-53389", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/tcp-ao: fix use-after-free of key in del_async path In tcp_ao_delete_key(), the del_async path skips the current_key and rnext_key validity checks present in the synchronous path, assuming these pointers are always NULL on LISTEN sockets. However, if a key was added with set_current=1/set_rnext=1 while the socket was in CLOSE state, current_key and rnext_key will be non-NULL after listen() transitions the socket to LISTEN. When such a key is deleted with del_async=1, hlist_del_rcu() and call_rcu() free the key without clearing the dangling pointers. After the RCU grace period, getsockopt(TCP_AO_INFO) dereferences current_key->sndid and rnext_key->rcvid from freed slab memory. Clear current_key and rnext_key in the del_async path when they reference the key being deleted.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53393", "url": "https://ubuntu.com/security/CVE-2026-53393", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: reset write verifier on deferred writeback errors nfsd_vfs_write() and nfsd_commit() both call filemap_check_wb_err() to detect deferred writeback errors, but neither rotates the server's write verifier (nn->writeverf) when this check fails. Every other durable-storage-failure path in these functions calls commit_reset_write_verifier() before returning an error. The missing rotation means clients holding UNSTABLE write data under the current verifier will COMMIT, receive the unchanged verifier back, and conclude their data is durable — silently dropping data that failed writeback. This violates the UNSTABLE+COMMIT durability contract (RFC 1813 §3.3.7, RFC 8881 §18.32). Add commit_reset_write_verifier() calls at both filemap_check_wb_err() error sites, matching the pattern used by adjacent error paths in the same functions. The helper already filters -EAGAIN and -ESTALE internally, so the calls are unconditionally safe.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53400", "url": "https://ubuntu.com/security/CVE-2026-53400", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: core: fix adapter registration race Adapters can be looked up based on their id using i2c_get_adapter() which takes a reference to the embedded struct device. Make sure that the adapter (including its struct device) has been initialised before adding it to the IDR to avoid accessing uninitialised data which could, for example, lead to NULL-pointer dereferences or use-after-free. Note that the i2c-dev chardev, which is registered from a bus notifier, currently uses i2c_get_adapter() so the adapter needs to be added to the IDR before registration.", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63806", "url": "https://ubuntu.com/security/CVE-2026-63806", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: Replace guest-triggerable BUG_ON() in ioeventfd datamatch with get_unaligned() Drop a BUG_ON() that has been reachable since it was first added, way back in 2009, and instead use get_unaligned() to perform potentially-unaligned accesses. For a given store, KVM x86's emulator tracks the entire value in the destination operand, x86_emulate_ctxt.dst. If the destination is memory, and the target splits multiple pages and/or is emulated MMIO, then KVM handles each fragment independently. E.g. on a page split starting at page offset 0xffc, KVM writes 4 bytes to the first page, then the remaining bytes to the second page, using ctxt->dst as the source for both (with appropriate offsets). If the destination splits a page *and* hits emulated MMIO on the second page, then KVM will complete the write to the first page, then emulate the MMIO access to the second page. If there is a datamatch-enabled ioeventfd at offset 0 of the second page, then KVM will process the remainder of the store as a potential ioeventfd signal. Putting it all together, if the guest emits a store that splits a page starting at page offset N, and the second page has a datamatch-enabled ioeventfd at offset 0, then KVM will check for datamatch using &dst.valptr[N] as the source. Due to dst (and thus dst.valptr) being 32-byte aligned, if N is not aligned to @len, the BUG_ON() fires. E.g. with a 16-byte store at page offset 0xffc, to an ioeventfd of len 8, all initial checks in ioeventfd_in_range() will succeed, and the BUG_ON() fires due to @val being 4-byte aligned, but not 8-byte aligned. ------------[ cut here ]------------ kernel BUG at arch/x86/kvm/../../../virt/kvm/eventfd.c:783! Oops: invalid opcode: 0000 [#1] SMP CPU: 0 UID: 1000 PID: 615 Comm: repro Not tainted 7.1.0-rc2-ff238429d1ea #365 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:ioeventfd_write+0x6c/0x70 [kvm] Call Trace: __kvm_io_bus_write+0x85/0xb0 [kvm] kvm_io_bus_write+0x53/0x80 [kvm] vcpu_mmio_write+0x66/0xf0 [kvm] emulator_read_write_onepage+0x12a/0x540 [kvm] emulator_read_write+0x109/0x2b0 [kvm] x86_emulate_insn+0x4f8/0xfb0 [kvm] x86_emulate_instruction+0x181/0x790 [kvm] kvm_mmu_page_fault+0x313/0x630 [kvm] vmx_handle_exit+0x18a/0x590 [kvm_intel] kvm_arch_vcpu_ioctl_run+0xc81/0x1c90 [kvm] kvm_vcpu_ioctl+0x2d5/0x970 [kvm] __x64_sys_ioctl+0x8a/0xd0 do_syscall_64+0xb7/0x890 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f19c931a9bf Modules linked in: kvm_intel kvm irqbypass ---[ end trace 0000000000000000 ]--- In a perfect world, the fix would be to simply delete the BUG_ON(), as KVM x86 doesn't perform alignment checks on \"normal\" memory accesses at CPL0. Sadly, C99 ruins all the fun; while the x86 architecture plays nice, dereferencing an unaligned pointer directly is undefined behavior in C, e.g. triggers splats when running with CONFIG_UBSAN_ALIGNMENT=y.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63940", "url": "https://ubuntu.com/security/CVE-2026-63940", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: SEV: Ignore Port I/O requests of length '0' Explicitly ignore Port I/O requests of length '0' (or count '0'), so that setting up the software scratch area (and other code) doesn't have to worry about underflowing the length, and to allow for WARNing on trying to configure the scratch area with len==0.", "cve_priority": "critical", "cve_public_date": "2026-07-19 16:17:00 UTC" }, { "cve": "CVE-2026-53387", "url": "https://ubuntu.com/security/CVE-2026-53387", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: light: veml6075: add bounds check to veml6075_it_ms index veml6075_it_ms has 5 elements but VEML6075_CONF_IT can yield values 0-7. If it returns a value >= 5, this causes an out-of-bounds array access. Add a bounds check and return -EINVAL if the index is out of range. The problem values are reserved so should never be read from the register. Hence this is hardening against fault device, missprogramming or bus corruption.", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53070", "url": "https://ubuntu.com/security/CVE-2026-53070", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: disable BH before calling udp_tunnel_xmit_skb() udp_tunnel_xmit_skb() / udp_tunnel6_xmit_skb() are expected to run with BH disabled. After commit 6f1a9140ecda (\"add xmit recursion limit to tunnel xmit functions\"), on the path: udp(6)_tunnel_xmit_skb() -> ip(6)tunnel_xmit() dev_xmit_recursion_inc()/dec() must stay balanced on the same CPU. Without local_bh_disable(), the context may move between CPUs, which can break the inc/dec pairing. This may lead to incorrect recursion level detection and cause packets to be dropped in ip(6)_tunnel_xmit() or __dev_queue_xmit(). Fix it by disabling BH around both IPv4 and IPv6 SCTP UDP xmit paths. In my testing, after enabling the SCTP over UDP: # ip net exec ha sysctl -w net.sctp.udp_port=9899 # ip net exec ha sysctl -w net.sctp.encap_port=9899 # ip net exec hb sysctl -w net.sctp.udp_port=9899 # ip net exec hb sysctl -w net.sctp.encap_port=9899 # ip net exec ha iperf3 -s - without this patch: # ip net exec hb iperf3 -c 192.168.0.1 --sctp [ 5] 0.00-10.00 sec 37.2 MBytes 31.2 Mbits/sec sender [ 5] 0.00-10.00 sec 37.1 MBytes 31.1 Mbits/sec receiver - with this patch: # ip net exec hb iperf3 -c 192.168.0.1 --sctp [ 5] 0.00-10.00 sec 3.14 GBytes 2.69 Gbits/sec sender [ 5] 0.00-10.00 sec 3.14 GBytes 2.69 Gbits/sec receiver", "cve_priority": "low", "cve_public_date": "2026-06-24 17:17:00 UTC" }, { "cve": "CVE-2026-43216", "url": "https://ubuntu.com/security/CVE-2026-43216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: Drop the lock in skb_may_tx_timestamp() skb_may_tx_timestamp() may acquire sock::sk_callback_lock. The lock must not be taken in IRQ context, only softirq is okay. A few drivers receive the timestamp via a dedicated interrupt and complete the TX timestamp from that handler. This will lead to a deadlock if the lock is already write-locked on the same CPU. Taking the lock can be avoided. The socket (pointed by the skb) will remain valid until the skb is released. The ->sk_socket and ->file member will be set to NULL once the user closes the socket which may happen before the timestamp arrives. If we happen to observe the pointer while the socket is closing but before the pointer is set to NULL then we may use it because both pointer (and the file's cred member) are RCU freed. Drop the lock. Use READ_ONCE() to obtain the individual pointer. Add a matching WRITE_ONCE() where the pointer are cleared.", "cve_priority": "medium", "cve_public_date": "2026-05-06 12:16:00 UTC" }, { "cve": "CVE-2026-64244", "url": "https://ubuntu.com/security/CVE-2026-64244", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drivers/base/memory: set mem->altmap after successful device registration If __add_memory_block() fails at xa_store() (under memory pressure for example), device_unregister() is called, which eventually triggers memory_block_release() with mem->altmap still set, causing a WARN_ON(mem->altmap). This was triggered by modifying virtio-mem driver. Fix this by delaying the assignment of mem->altmap until after __add_memory_block() has succeeded.", "cve_priority": "medium", "cve_public_date": "2026-07-24 16:16:00 UTC" }, { "cve": "CVE-2026-53384", "url": "https://ubuntu.com/security/CVE-2026-53384", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: 8250_dw: unregister 8250 port if clk_notifier_register() fails dw8250_probe() registers the 8250 port via serial8250_register_8250_port() and then, if the device has a clock, registers a clock notifier. If clk_notifier_register() fails, probe returns the error but leaves the 8250 port registered. The matching serial8250_unregister_port() lives in dw8250_remove(), which is not called when probe fails, so the port slot stays occupied until the device is rebound or the system is rebooted. The devm-allocated driver data is freed while the port still references it (via the saved private_data and serial_in/serial_out callbacks), so any access to that port slot before a rebind is a use-after-free hazard. Unregister the port on the clk_notifier_register() error path.", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53390", "url": "https://ubuntu.com/security/CVE-2026-53390", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix out-of-bounds read in smb_check_perm_dacl() The permission-check ACE walk in smb_check_perm_dacl() validates the ACE header size and caps sid.num_subauth at SID_MAX_SUB_AUTHORITIES, but it never checks that ace->size is actually large enough to contain num_subauth sub-authorities before compare_sids() dereferences them. CIFS_SID_BASE_SIZE covers the SID header up to but excluding the sub_auth[] array, and offsetof(struct smb_ace, sid) is the ACE header, so the existing guards only guarantee the 8-byte SID base, i.e. zero sub-authorities. compare_sids() then reads ace->sid.sub_auth[i] for i < min(local_sid->num_subauth, ace->sid.num_subauth). The local comparison SIDs (sid_everyone, sid_unix_NFS_mode, and the id_to_sid() result) always have at least one sub-authority, and an attacker controls the ACE revision and authority bytes (which lie within the in-bounds SID base), so they can match one of those SIDs and force the sub_auth read. A crafted ACE with size == 16 and num_subauth >= 1 placed at the tail of the security descriptor therefore causes a heap out-of-bounds read of up to SID_MAX_SUB_AUTHORITIES * sizeof(__le32) bytes past the pntsd allocation. The security descriptor is loaded by ksmbd_vfs_get_sd_xattr() into a buffer sized exactly to the on-disk data (kzalloc(sd_size) in ndr_decode_v4_ntacl()), so the read lands past the allocation. The malformed descriptor can be stored verbatim via SMB2_SET_INFO (the DACL is not normalised before being written to the security.NTACL xattr) and the read fires on a subsequent SMB2_CREATE access check, making this reachable by an authenticated client on a share that uses ACL xattrs. Add the missing num_subauth-versus-ace_size check, mirroring the identical guards already present in the sibling parsers parse_dacl() and smb_inherit_dacl().", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53391", "url": "https://ubuntu.com/security/CVE-2026-53391", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4/pNFS: reject zero-length r_addr in nfs4_decode_mp_ds_addr nfs4_decode_mp_ds_addr() decodes the r_netid and r_addr opaques of a netaddr4 from a GETDEVICEINFO multipath-DS body, then immediately calls strrchr(buf, '.') to locate the port separator. Both decodes use xdr_stream_decode_string_dup(), and the current code checks only \"nlen < 0\" / \"rlen < 0\" before dereferencing the returned string. When the on-wire opaque has length zero, xdr_stream_decode_opaque_inline() returns 0 and xdr_stream_decode_string_dup() falls through to its \"*str = NULL; return ret\" tail, leaving buf NULL with a return value of 0. The \"< 0\" check does not catch this, and the next line is strrchr(NULL, '.'), a kernel NULL pointer dereference reachable from any pNFS-flexfile client mounted against a malicious or compromised metadata server. Reject the zero-length cases explicitly so the decoder fails with -EBADMSG (treated as a malformed GETDEVICEINFO body) instead of panicking the client.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53397", "url": "https://ubuntu.com/security/CVE-2026-53397", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: fix posix_acl leak on SETACL decode failure nfsaclsvc_decode_setaclargs() and nfs3svc_decode_setaclargs() each call nfs_stream_decode_acl() twice, first for NFS_ACL and then for NFS_DFACL. Each successful call transfers ownership of a freshly allocated posix_acl into argp->acl_access or argp->acl_default. If the first call succeeds but the second fails, the decoder returns false and argp->acl_access is left dangling. ACLPROC2_SETACL.pc_release was wired to nfssvc_release_attrstat and ACLPROC3_SETACL.pc_release was wired to nfs3svc_release_fhandle. Both only call fh_put() and have no knowledge of the ACL fields on argp. The posix_acl_release() pairs sat at the out: labels inside nfsacld_proc_setacl() and nfsd3_proc_setacl(), but svc_process() skips pc_func when pc_decode returns false, so that cleanup is unreachable on decode failure: svc_process_common() pc_decode() /* decode_setaclargs: false */ /* pc_func skipped */ pc_release() /* fh_put only -- ACLs leaked */ The orphaned posix_acl is leaked for the lifetime of the server. Fix by adding nfsaclsvc_release_setacl() and nfs3svc_release_setacl(), which release both argp->acl_access and argp->acl_default in addition to fh_put(), and wiring them as pc_release for their respective SETACL procedures. pc_release runs on every path svc_process() takes after decode, including decode failure, so the posix_acl_release() pairs are removed from the proc functions' out: labels to keep ownership in one place. This matches the existing release_getacl() pattern used by the sibling GETACL procedures.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53398", "url": "https://ubuntu.com/security/CVE-2026-53398", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSD: Fix SECINFO_NO_NAME decode error cleanup nfsd4_decode_secinfo_no_name() currently initializes sin_exp after decoding sin_style. If the XDR stream is truncated, the decoder returns nfserr_bad_xdr before sin_exp is initialized. Since commit 3fdc54646234 (\"NFSD: Reduce amount of struct nfsd4_compoundargs that needs clearing\"), the inline iops array is not cleared between RPC calls. A failed SECINFO_NO_NAME decode can therefore leave sin_exp holding stale union contents from a previous operation. The error response path still invokes nfsd4_secinfo_no_name_release(), which calls exp_put() on a non-NULL sin_exp. Initialize sin_exp before the first failable decode step, matching nfsd4_decode_secinfo().", "cve_priority": "critical", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-64245", "url": "https://ubuntu.com/security/CVE-2026-64245", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: modedb: fix a possible UAF in fb_find_mode() If mode_option is NULL, it is assigned from mode_option_buf: if (!mode_option) { fb_get_options(NULL, &mode_option_buf); mode_option = mode_option_buf; } Later, name is assigned from mode_option: const char *name = mode_option; However, mode_option_buf is freed before name is no longer used: kfree(mode_option_buf); while name is still accessed by: if ((name_matches(db[i], name, namelen) || Since name aliases mode_option_buf, this may result in a use-after-free. Fix this by extending the lifetime of mode_option_buf until the end of the function by using scope-based resource management for cleanup.", "cve_priority": "low", "cve_public_date": "2026-07-24 16:16:00 UTC" }, { "cve": "CVE-2026-53403", "url": "https://ubuntu.com/security/CVE-2026-53403", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: Fix fb_new_modelist to prevent null-ptr-deref in fb_videomode_to_var info->var, a framebuffer's current mode, is expected to have a matching entry in info->modelist. var_to_display() relies on this and treats a failed fb_match_mode() as \"This should not happen\". fb_set_var() keeps it true by adding the mode to the list on every change, and do_register_framebuffer() does the same at registration. store_modes() replaces the modelist from userspace. fb_new_modelist() validates the new modes but does not check that info->var still has a match. It relies on fbcon_new_modelist() to re-point consoles, but that only handles consoles mapped to the framebuffer. With fbcon unbound there are none, so info->var is left describing a mode that is no longer in the list. A later console takeover runs var_to_display(), where fb_match_mode() returns NULL and leaves fb_display[i].mode NULL. fbcon_switch() passes it to display_to_var(), and fb_videomode_to_var() dereferences the NULL mode. Keep the current mode in the list in fb_new_modelist(), the same way fb_set_var() does.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-64246", "url": "https://ubuntu.com/security/CVE-2026-64246", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: power: reset: linkstation-poweroff: fix use-after-free in the linkstation_poweroff_init() Move of_node_put(dn) after the of_match_node() call, which still needs the node pointer. The node reference is correctly released after use.", "cve_priority": "medium", "cve_public_date": "2026-07-24 16:16:00 UTC" }, { "cve": "CVE-2026-63794", "url": "https://ubuntu.com/security/CVE-2026-63794", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: SVM: Fix page overflow in sev_dbg_crypt() for ENCRYPT path In sev_dbg_crypt(), the per-iteration transfer length is bounded by the source page offset (PAGE_SIZE - s_off) but not by the destination page offset (PAGE_SIZE - d_off). When d_off > s_off, the encrypt path (__sev_dbg_encrypt_user) performs a read-modify-write using a single-page intermediate buffer (dst_tpage): 1. __sev_dbg_decrypt() expands the size to round_up(len + (d_off & 15), 16) before issuing the PSP command. If len + (d_off & 15) > PAGE_SIZE, the PSP writes beyond the end of the 4096-byte dst_tpage allocation. 2. The subsequent memcpy()/copy_from_user() into page_address(dst_tpage) + (d_off & 15) of 'len' bytes overflows by up to 15 bytes under the same condition. Trigger example: s_off = 0, d_off = 1, debug.len = PAGE_SIZE - the PSP is instructed to write round_up(4097, 16) = 4112 bytes to a 4096-byte buffer. Fix by also bounding len by (PAGE_SIZE - d_off), the same check that sev_send_update_data() already performs for its single-page guest region. ================================================================== BUG: KASAN: slab-use-after-free in sev_dbg_crypt+0x993/0xd10 [kvm_amd] Write of size 4095 at addr ff110062293bb009 by task sev_dbg_test/228214 CPU: 96 UID: 0 PID: 228214 Comm: sev_dbg_test Tainted: G U W 7.0.0-smp--5ce9b0c48211-dbg #156 PREEMPTLAZY Tainted: [U]=USER, [W]=WARN Hardware name: Google Astoria/astoria, BIOS 0.20250817.1-0 08/25/2025 Call Trace: dump_stack_lvl+0x54/0x70 print_report+0xbc/0x260 kasan_report+0xa2/0xd0 kasan_check_range+0x25f/0x2c0 __asan_memcpy+0x40/0x70 sev_dbg_crypt+0x993/0xd10 [kvm_amd] sev_mem_enc_ioctl+0x33c/0x450 [kvm_amd] kvm_vm_ioctl+0x65d/0x6d0 [kvm] __se_sys_ioctl+0xb2/0x100 do_syscall_64+0xe8/0x870 entry_SYSCALL_64_after_hwframe+0x4b/0x53 The buggy address belongs to the physical page: page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x7fe72b6a0 pfn:0x62293bb memcg:ff11000112827d82 flags: 0x1400000000000000(node=1|zone=1) raw: 1400000000000000 0000000000000000 dead000000000122 0000000000000000 raw: 00000007fe72b6a0 0000000000000000 00000001ffffffff ff11000112827d82 page dumped because: kasan: bad access detected Memory state around the buggy address: ff110062293bbf00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff110062293bbf80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ff110062293bc000: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc ^ ff110062293bc080: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc ff110062293bc100: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc ================================================================== Disabling lock debugging due to kernel taint [sean: add sample KASAN splat, Fixes, and stable@]", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-64247", "url": "https://ubuntu.com/security/CVE-2026-64247", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86: hyper-v: Bound the bank index when querying sparse banks When checking if a VP ID is included in a sparse bank set, explicitly check that the ID can actually be contained in a sparse bank (the TLFS allows for a maximum of 64 banks of 64 vCPUs each). When handling a paravirtual TLB flush for L2, the VP ID is copied verbatim from the enlightened VMCS, without any bounds check, i.e. isn't guaranteed to be under the limit of 4096. Failure to check the bounds of the VP ID leads to an out-of-bounds read when testing the sparse bank, and super strictly speaking could lead to KVM performing an unnecessary TLB flush for an L2 vCPU. ================================================================== BUG: KASAN: use-after-free in hv_is_vp_in_sparse_set+0x85/0x100 [kvm] Read of size 8 at addr ffff88811ba5f598 by task hyperv_evmcs/2802 CPU: 12 UID: 1000 PID: 2802 Comm: hyperv_evmcs Not tainted 7.1.0-rc2 #7 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Call Trace: dump_stack_lvl+0x51/0x60 print_report+0xcb/0x5d0 kasan_report+0xb4/0xe0 kasan_check_range+0x35/0x1b0 hv_is_vp_in_sparse_set+0x85/0x100 [kvm] kvm_hv_flush_tlb+0xe9e/0x16c0 [kvm] kvm_hv_hypercall+0xe6b/0x1e60 [kvm] vmx_handle_exit+0x485/0x1b60 [kvm_intel] kvm_arch_vcpu_ioctl_run+0x22e3/0x5070 [kvm] kvm_vcpu_ioctl+0x5d0/0x10c0 [kvm] __x64_sys_ioctl+0x129/0x1a0 do_syscall_64+0xb9/0xcf0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f0e62d1a9bf The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffffffffffffffff pfn:0x11ba5f flags: 0x4000000000000000(zone=1) raw: 4000000000000000 0000000000000000 00000000ffffffff 0000000000000000 raw: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff88811ba5f480: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff88811ba5f500: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff >ffff88811ba5f580: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ^ ffff88811ba5f600: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff88811ba5f680: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ================================================================== Disabling lock debugging due to kernel taint Opportunistically add a compile time assertion to ensure the maximum number of sparse banks exactly matches the number of possible bits in the passed in mask. [sean: add KASAN splat, drop comment, add assert, massage changelog]", "cve_priority": "medium", "cve_public_date": "2026-07-24 16:16:00 UTC" }, { "cve": "CVE-2026-63795", "url": "https://ubuntu.com/security/CVE-2026-63795", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: 9p: avoid putting oldfid in p9_client_walk() error path When p9_client_walk() is called with clone set to false, fid aliases oldfid. If the walk subsequently fails after the request has been sent, the error path jumps to clunk_fid, which currently calls p9_fid_put(fid) unconditionally. This drops a reference to oldfid even though ownership of oldfid remains with the caller. If this is the last reference, oldfid can be clunked and destroyed while the caller still expects it to be valid. A later use or put of oldfid can then trigger a use-after-free or refcount underflow. Fix this by only putting fid in the clunk_fid error path when it does not alias oldfid, matching the existing guard in the error path below. This can be triggered when a multi-component walk is split into multiple p9_client_walk() calls and a later non-cloning walk fails. A reproducer and refcount warning logs are available on request.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63796", "url": "https://ubuntu.com/security/CVE-2026-63796", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: reject oversized group bitmap descriptors ocfs2_validate_gd_parent() only bounds bg_bits against the parent allocator's chain geometry. A malicious descriptor can still claim a bg_size/bg_bits pair that exceeds the bitmap bytes that physically fit in the group descriptor block, so later bitmap scans and bit updates can run past bg_bitmap. Add a physical-cap check based on ocfs2_group_bitmap_size() for the parent allocator type and reject descriptors whose bg_size or bg_bits exceed that capacity. Keep the existing chain geometry check so both the on-disk bitmap layout and the allocator metadata must agree before the descriptor is used. Validation reproduced this kernel report: KASAN use-after-free in _find_next_bit+0x7f/0xc0 Read of size 8 Call trace: dump_stack_lvl+0x66/0xa0 (?:?) print_report+0xd0/0x630 (?:?) _find_next_bit+0x7f/0xc0 (?:?) srso_alias_return_thunk+0x5/0xfbef5 (?:?) __virt_addr_valid+0x188/0x2f0 (?:?) kasan_report+0xe4/0x120 (?:?) ocfs2_find_max_contig_free_bits+0x35/0x70 (fs/ocfs2/suballoc.c:1375) ocfs2_block_group_set_bits+0x472/0x4b0 (fs/ocfs2/suballoc.c:1457) ocfs2_cluster_group_search+0x16b/0x440 (fs/ocfs2/suballoc.c:86) ocfs2_bg_discontig_fix_result+0x1ef/0x230 (fs/ocfs2/suballoc.c:1786) ocfs2_search_chain+0x8f8/0x10a0 (fs/ocfs2/suballoc.c:1886) get_page_from_freelist+0x70e/0x2370 (?:?) lock_release+0xc6/0x290 (?:?) do_raw_spin_unlock+0x9a/0x100 (?:?) kasan_unpoison+0x27/0x60 (?:?) __bfs+0x147/0x240 (?:?) get_page_from_freelist+0x83d/0x2370 (?:?) ocfs2_claim_suballoc_bits+0x38c/0xe70 (fs/ocfs2/suballoc.c:96) sched_domains_numa_masks_clear+0x70/0xd0 (?:?) check_irq_usage+0xe8/0xb70 (?:?) __ocfs2_claim_clusters+0x18d/0x4c0 (fs/ocfs2/suballoc.c:2497) check_path+0x24/0x50 (?:?) rcu_is_watching+0x20/0x50 (?:?) check_prev_add+0xfd/0xd00 (?:?) ocfs2_add_clusters_in_btree+0x17d/0x810 (fs/ocfs2/suballoc.c:?) __folio_batch_add_and_move+0x1f5/0x3d0 (?:?) ocfs2_add_inode_data+0xd9/0x120 (fs/ocfs2/suballoc.c:?) filemap_add_folio+0x105/0x1f0 (?:?) ocfs2_write_begin_nolock+0x29f7/0x2f80 (fs/ocfs2/suballoc.c:3043) ocfs2_read_inode_block+0xb5/0x110 (fs/ocfs2/suballoc.c:?) down_write+0xf5/0x180 (?:?) ocfs2_write_begin+0x180/0x240 (fs/ocfs2/suballoc.c:?) __mark_inode_dirty+0x758/0x9a0 (?:?) inode_to_bdi+0x41/0x90 (?:?) balance_dirty_pages_ratelimited_flags+0xf8/0x1d0 (?:?) generic_perform_write+0x252/0x440 (?:?) mnt_put_write_access_file+0x16/0x70 (?:?) file_update_time_flags+0xe4/0x200 (?:?) ocfs2_file_write_iter+0x80a/0x1320 (fs/ocfs2/suballoc.c:?) lock_acquire+0x184/0x2f0 (?:?) ksys_write+0xd2/0x170 (?:?) apparmor_file_permission+0xf5/0x310 (?:?) read_zero+0x8d/0x140 (?:?) lock_is_held_type+0x8f/0x100 (?:?)", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63797", "url": "https://ubuntu.com/security/CVE-2026-63797", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rpmsg: char: Fix use-after-free on probe error path rpmsg_chrdev_probe() stores the newly allocated eptdev in the default endpoint's priv pointer before calling rpmsg_chrdev_eptdev_add(). If rpmsg_chrdev_eptdev_add() then fails, its error path frees eptdev while the default endpoint may still dispatch callbacks with the stale priv pointer. Avoid publishing eptdev through the default endpoint until rpmsg_chrdev_eptdev_add() succeeds. Messages received before the priv pointer is published should be ignored by rpmsg_ept_cb(). Flow-control updates can hit rpmsg_ept_flow_cb() in the same window, so make both callbacks return success when priv is NULL.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-64249", "url": "https://ubuntu.com/security/CVE-2026-64249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fpga: region: fix use-after-free in child_regions_with_firmware() Move of_node_put(child_region) after the error print to avoid accessing freed memory when pr_err() references child_region. [ Yilun: Fix the Fixes tag ]", "cve_priority": "low", "cve_public_date": "2026-07-24 16:16:00 UTC" }, { "cve": "CVE-2026-63798", "url": "https://ubuntu.com/security/CVE-2026-63798", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: irqchip/imgpdc: Fix resource leak, add missing chained handler cleanup on remove The driver allocates domain generic chips using irq_alloc_domain_generic_chips() during probe and sets up chained handlers using irq_set_chained_handler_and_data(). However, on driver removal, the generic chips are not freed and the chained handlers are not removed. The generic chips remain on the global gc_list and may later be accessed by generic interrupt chip suspend, resume, or shutdown callbacks after the driver has been removed, potentially resulting in a use-after-free and kernel crash. The chained handlers that were installed in probe for peripheral and syswake interrupts are also left dangling, which can lead to spurious interrupts accessing freed memory. Fix these issues by: - Setting IRQ_DOMAIN_FLAG_DESTROY_GC flag in domain->flags, so the core code automatically removes generic chips when irq_domain_remove() is called - Clearing all chained handlers with NULL in pdc_intc_remove()", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63800", "url": "https://ubuntu.com/security/CVE-2026-63800", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pNFS: Fix use-after-free in pnfs_update_layout() When hitting the NFS_LAYOUT_RETURN branch in pnfs_update_layout(), the code calls pnfs_prepare_to_retry_layoutget(lo). If it succeeds, pnfs_put_layout_hdr(lo) is called before trace_pnfs_update_layout(), which still references 'lo'. This results in a use-after-free when the tracepoint accesses lo's fields. Fix this by moving the tracepoint call before pnfs_put_layout_hdr(lo).", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63801", "url": "https://ubuntu.com/security/CVE-2026-63801", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: fix slab-use-after-free Read in tipc_aead_decrypt_done tipc_aead_decrypt() goes straight from tipc_bearer_hold(b) to crypto_aead_decrypt(req) without taking a reference on the netns, unlike the encrypt path. When crypto_aead_decrypt() is offloaded asynchronously (e.g. the SIMD aead wrapper queuing to cryptd), the cryptd worker runs tipc_aead_decrypt_done() later. If the bearer's netns is torn down in the meantime, cleanup_net() -> tipc_exit_net() -> tipc_crypto_stop() frees the per-netns tipc_crypto, and the completion then reads it: tipc_aead_decrypt_done() dereferences aead->crypto->stats and aead->crypto->net, and tipc_crypto_rcv_complete() dereferences aead->crypto->aead[] and the node table -- reading freed memory. Decoded KASAN splat (v7.1-rc7, CONFIG_KASAN_INLINE + TIPC + TIPC_CRYPTO): BUG: KASAN: slab-use-after-free in tipc_aead_decrypt_done (net/tipc/crypto.c:999) Read of size 8 at addr ffff8881056258a8 by task kworker/u16:2/51 Workqueue: events_unbound Call Trace: tipc_aead_decrypt_done (net/tipc/crypto.c:999) process_one_work (kernel/workqueue.c:3314) worker_thread (kernel/workqueue.c:3397 kernel/workqueue.c:3478) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) Allocated by task 169: __kasan_kmalloc (mm/kasan/common.c:398 mm/kasan/common.c:415) tipc_crypto_start (net/tipc/crypto.c:1502) tipc_init_net (net/tipc/core.c:72) ops_init (net/core/net_namespace.c:137) setup_net (net/core/net_namespace.c:446) copy_net_ns (net/core/net_namespace.c:579) create_new_namespaces (kernel/nsproxy.c:132) __x64_sys_unshare (kernel/fork.c:3316) do_syscall_64 (arch/x86/entry/syscall_64.c:63) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Freed by task 8: kfree (mm/slub.c:6566) tipc_exit_net (net/tipc/core.c:119) cleanup_net (net/core/net_namespace.c:704) process_one_work (kernel/workqueue.c:3314) kthread (kernel/kthread.c:436) This is the same class of bug that commit e279024617134 (\"net/tipc: fix slab-use-after-free Read in tipc_aead_encrypt_done\") fixed for the encrypt side. The encrypt path takes maybe_get_net(aead->crypto->net) before crypto_aead_encrypt() and drops it with put_net() on the synchronous return paths and in tipc_aead_encrypt_done(); the -EINPROGRESS/-EBUSY return keeps the reference for the async callback to release. The decrypt path was left without the equivalent guard. Mirror the encrypt-side fix on the decrypt path: take a net reference before crypto_aead_decrypt() (failing with -ENODEV and the matching bearer put if it cannot be acquired), keep it across the -EINPROGRESS/-EBUSY async return, and drop it with put_net() on the synchronous success/error return and at the end of tipc_aead_decrypt_done(). Reproduced under KASAN on v7.1-rc7: a UDP bearer with a cluster key is flooded with crafted encrypted frames from an unknown peer (driving the cluster-key decrypt path) while the bearer's netns is repeatedly torn down. The completion must run asynchronously to outlive tipc_crypto_stop(); on x86 the stock aesni gcm(aes) now decrypts synchronously, so the async path was exercised via cryptd offload. The unguarded aead->crypto dereference in tipc_aead_decrypt_done() is the unpatched upstream path; tipc_aead_decrypt() still lacks maybe_get_net(aead->crypto->net), so the completion can outlive the free on any config where crypto_aead_decrypt() goes async. Found by 0sec automated security-research tooling (https://0sec.ai).", "cve_priority": "high", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63802", "url": "https://ubuntu.com/security/CVE-2026-63802", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: blk-cgroup: fix UAF in __blkcg_rstat_flush() When multiple blkgs in the same blkcg are released concurrently, a use-after-free can occur. The race happens when one blkg's __blkcg_rstat_flush() removes another blkg's iostat entries via llist_del_all(). The second blkg sees an empty list and proceeds to free itself while the first is still iterating over its entries. Move the flush from __blkg_release() (RCU callback) to blkg_release() (before call_rcu). This ensures the RCU grace period waits for any concurrent flush's rcu_read_lock() section to complete before freeing.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63803", "url": "https://ubuntu.com/security/CVE-2026-63803", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hdlc_ppp: sync per-proto timers before freeing hdlc state Each PPP control protocol (LCP/IPCP/IPV6CP) embedded in struct ppp registers a timer via timer_setup(). That struct ppp is the hdlc->state allocation, which detach_hdlc_protocol() frees with kfree() in both teardown paths: unregister_hdlc_device() and the re-attach inside attach_hdlc_protocol(). The ppp proto never registered a .detach callback, so detach_hdlc_protocol() performs no timer synchronization before the kfree(). The only cancel, timer_delete(&proto->timer) in ppp_cp_event(), is partial (it does not wait for a running callback) and only runs on the ->CLOSED transition; ppp_stop()/ppp_close() do not sync either. A ppp_timer callback already executing (blocked on ppp->lock) survives the kfree and then dereferences proto->state / ppp->lock in freed memory, leading to a use-after-free. Fix this by adding a .detach helper that calls timer_shutdown_sync() on every per-proto timer. detach_hdlc_protocol() invokes proto->detach(dev) before kfree(hdlc->state), so timer_shutdown_sync() now runs on both free paths. timer_shutdown_sync() is used instead of timer_delete_sync() because the keepalive path re-arms the timer through add_timer()/mod_timer() and shutdown blocks any re-activation during teardown. Initialize the per-protocol timers in ppp_ioctl() when the protocol is attached, and remove the now-redundant timer_setup() from ppp_start(), so that the timers are initialized exactly once at attach time and ppp_timer_release() never operates on uninitialized timer_list structures. attach_hdlc_protocol() uses kmalloc() (not kzalloc), so struct ppp's protos[i].timer is uninitialized garbage until the first timer_setup(); without this init-at-attach, attaching the PPP protocol without ever bringing the device up would leave timer_shutdown_sync() operating on uninitialized memory in .detach. Moving the init out of ppp_start() (which only runs on NETDEV_UP) into the attach path makes the initialization unconditional and avoids initializing the same timer_list twice. This bug was found by static analysis.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63804", "url": "https://ubuntu.com/security/CVE-2026-63804", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gfs2: fix use-after-free in gfs2_qd_dealloc gfs2_qd_dealloc(), called as an RCU callback from gfs2_qd_dispose(), accesses the superblock object sdp through qd->qd_sbd after freeing qd. It does so to decrement sd_quota_count and wake up sd_kill_wait. However, by the time the RCU callback runs, gfs2_put_super() may have already freed sdp via free_sbd(). This can happen when gfs2_quota_cleanup() is called during unmount: it disposes of quota objects via call_rcu() and then waits on sd_kill_wait with a 60-second timeout. If the timeout expires, or if gfs2_gl_hash_clear() triggers additional qd_put() calls that schedule more RCU callbacks after the wait completes, gfs2_put_super() will proceed to free the superblock while RCU callbacks referencing it are still pending. Add an rcu_barrier() before free_sbd() in gfs2_put_super() to ensure all pending RCU callbacks (including gfs2_qd_dealloc) have completed before the superblock is freed.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63808", "url": "https://ubuntu.com/security/CVE-2026-63808", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exfat: fix potential use-after-free in exfat_find_dir_entry() In exfat_find_dir_entry(), the buffer_head obtained from exfat_get_dentry() is released with brelse(bh) before the fall-through TYPE_EXTEND branch reads the directory entry through ep (which points into bh->b_data): \tbrelse(bh); \tif (entry_type == TYPE_EXTEND) { \t\t... \t\tlen = exfat_extract_uni_name(ep, entry_uniname); \t\t... \t} After brelse() drops our reference, nothing guarantees that the underlying page backing bh->b_data remains valid for the subsequent exfat_extract_uni_name() read. This is the same pattern fixed in commit fc961522ddbd (\"exfat: Fix potential use after free in exfat_load_upcase_table()\"). Move brelse(bh) so it runs after ep is no longer dereferenced on each branch. Confirmed on QEMU x86_64 with CONFIG_KASAN=y + CONFIG_DEBUG_PAGEALLOC=y + CONFIG_PAGE_POISONING=y on linux-next, using a crafted exFAT image (long filename with same-hash collisions forcing the TYPE_EXTEND path). With a debug-only invalidate_bdev() inserted between brelse(bh) and the ep read to make the stale-deref window deterministic, the unpatched kernel faults: BUG: KASAN: use-after-free in exfat_find_dir_entry+0x133b/0x15a0 BUG: unable to handle page fault for address: ffff88801a5fa0c2 Oops: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI RIP: 0010:exfat_find_dir_entry+0x1188/0x15a0 With this patch applied, the same instrumented harness completes cleanly under the same sanitizer stack. I have not reproduced a crash on an uninstrumented kernel under ordinary reclaim; the instrumented A/B establishes the lifetime violation and that the patch closes it, not an unaided triggerability claim.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63809", "url": "https://ubuntu.com/security/CVE-2026-63809", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: use kvfree() for replaced sysctl write buffer proc_sys_call_handler() allocates its temporary sysctl buffer with kvzalloc() and passes it to __cgroup_bpf_run_filter_sysctl(). Since kvzalloc() may fall back to vmalloc() for large allocations, freeing that buffer with kfree() is wrong and can corrupt memory. Use kvfree() to safely handle both kmalloc and kvzalloc()/vmalloc allocations. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in v7.1-rc5. Reproduced the bug based on v7.1-rc4 in a QEMU x86_64 guest booted with KASAN and CONFIG_FAILSLAB enabled. To exercise the replacement path, the test tree also included the accompanying fix for the stale ret == 1 check in __cgroup_bpf_run_filter_sysctl(). The reproducer confines failslab injections to the proc_sys_call_handler() range, uses stacktrace-depth=32, and injects fail-nth=1 while writing 8191 bytes to /proc/sys/kernel/domainname from a task in the target cgroup. Under that setup, fail-nth=1 triggered the fault: BUG: unable to handle page fault for address: ffffeb0200024d48 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 SMP KASAN NOPTI CPU: 2 UID: 0 PID: 209 Comm: repro_proc_sys_ Not tainted 7.1.0-rc4-00686-g97625979a5d4 PREEMPT(lazy) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 RIP: 0010:kfree+0x6e/0x510 ... Call Trace: ? __cgroup_bpf_run_filter_sysctl+0x626/0xc30 __cgroup_bpf_run_filter_sysctl+0x74d/0xc30 ? __pfx___cgroup_bpf_run_filter_sysctl+0x10/0x10 ? srso_return_thunk+0x5/0x5f ? __kvmalloc_node_noprof+0x345/0x870 ? proc_sys_call_handler+0x250/0x480 ? srso_return_thunk+0x5/0x5f proc_sys_call_handler+0x3a2/0x480 ? __pfx_proc_sys_call_handler+0x10/0x10 ? srso_return_thunk+0x5/0x5f ? selinux_file_permission+0x39f/0x500 ? srso_return_thunk+0x5/0x5f ? lock_is_held_type+0x9e/0x120 vfs_write+0x98e/0x1000 ... With this fix applied on top of the same test setup, rerunning the reproducer with fail-nth=1 yields no corresponding Oops reports.", "cve_priority": "high", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63812", "url": "https://ubuntu.com/security/CVE-2026-63812", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix incorrect FI_NO_EXTENT handling in __destroy_extent_node() When __destroy_extent_node() sets the inode flag FI_NO_EXTENT, it does not reset the length of the largest extent to 0 and update the inode folio. Since modifications to the extent tree are disallowed afterward, the cached largest extent may become stale. This can trigger the following error in xfstests generic/388: F2FS-fs (dm-0): sanity_check_extent_cache: inode (ino=1761) extent info [220057, 57, 6] is incorrect, run fsck to fix In the f2fs_drop_inode path, __destroy_extent_node() does not need to guarantee that et->node_cnt is 0, because concurrency with writeback is expected in this path, and writeback may update the extent cache. This patch reverts commit ed78aeebef05 (\"f2fs: fix node_cnt race between extent node destroy and writeback\"), and remove the unnecessary zero check of et->node_cnt.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63814", "url": "https://ubuntu.com/security/CVE-2026-63814", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: validate ACL entry sizes in f2fs_acl_from_disk() f2fs_acl_count() only validates the aggregate ACL xattr length. A malformed ACL can still place ACL_USER or ACL_GROUP in a slot that only contains struct f2fs_acl_entry_short bytes, and f2fs_acl_from_disk() then reads entry->e_id before verifying that a full entry fits. Require a short entry before reading e_tag and e_perm, and require a full entry before reading e_id for ACL_USER and ACL_GROUP. Return -EFSCORRUPTED from these new truncated-entry checks, while keeping the pre-existing -EINVAL paths unchanged. Validation reproduced this kernel report: KASAN slab-out-of-bounds in __f2fs_get_acl+0x6fb/0x7e0 RIP: 0033:0x7f4b835ea7aa The buggy address belongs to the object at ffff888114589960 which belongs to the cache kmalloc-8 of size 8 The buggy address is located 0 bytes to the right of allocated 8-byte region [ffff888114589960, ffff888114589968) Read of size 4 Call trace: dump_stack_lvl+0x66/0xa0 (?:?) print_report+0xce/0x630 (?:?) __f2fs_get_acl+0x6fb/0x7e0 (fs/f2fs/acl.c:169) srso_alias_return_thunk+0x5/0xfbef5 (?:?) __virt_addr_valid+0x224/0x430 (?:?) kasan_report+0xe0/0x110 (?:?) __f2fs_get_acl+0x5/0x7e0 (fs/f2fs/acl.c:169) __get_acl+0x281/0x380 (?:?) vfs_get_acl+0x10b/0x190 (?:?) do_get_acl+0x2a/0x410 (?:?) do_get_acl+0x9/0x410 (?:?) do_getxattr+0xe8/0x260 (?:?) filename_getxattr+0xd1/0x140 (?:?) do_getname+0x2d/0x2d0 (?:?) path_getxattrat+0x16c/0x200 (?:?) lock_release+0xc8/0x290 (?:?) cgroup_update_frozen+0x9d/0x320 (?:?) lockdep_hardirqs_on_prepare+0xea/0x1a0 (?:?) trace_hardirqs_on+0x1a/0x170 (?:?) _raw_spin_unlock_irq+0x28/0x50 (?:?) do_syscall_64+0x115/0x6a0 (arch/x86/entry/syscall_64.c:87) entry_SYSCALL_64_after_hwframe+0x77/0x7f (?:?)", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63817", "url": "https://ubuntu.com/security/CVE-2026-63817", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: validate compress cache inode only when enabled F2FS_COMPRESS_INO() uses NM_I(sbi)->max_nid as the synthetic inode number for the compressed page cache inode. That inode only exists when the compress_cache mount option is enabled. When compress_cache is disabled, max_nid is outside the valid inode range. A corrupted directory entry that points to ino == max_nid should therefore be rejected by f2fs_check_nid_range(). However, is_meta_ino() currently treats F2FS_COMPRESS_INO() as a meta inode unconditionally, so f2fs_iget() bypasses do_read_inode() and its nid range check, and instantiates a fake internal inode instead. Gate the compressed cache inode case on COMPRESS_CACHE, matching f2fs_init_compress_inode(). With compress_cache disabled, ino == max_nid now follows the normal inode path and is rejected as an out-of-range nid.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63821", "url": "https://ubuntu.com/security/CVE-2026-63821", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw88: usb: fix memory leaks on USB write failures When rtw_usb_write_port() fails to submit a USB Request Block (URB) (e.g., due to device disconnect or ENOMEM), the completion callback is never executed. Currently, the driver ignores the return value of rtw_usb_write_port() in rtw_usb_write_data() and rtw_usb_tx_agg_skb(). Because these functions rely on the completion callback to free the socket buffers (skbs) and the transaction control block (txcb), a submission failure results in: 1. A memory leak of the allocated skb in rtw_usb_write_data(). 2. A memory leak of the txcb structure and all aggregated skbs in rtw_usb_tx_agg_skb(). Fix this by checking the return value of rtw_usb_write_port(). If it fails, explicitly free the skb in rtw_usb_write_data(), and properly purge the tx_ack_queue and free the txcb in rtw_usb_tx_agg_skb(). The issue was discovered in practice during device disconnect/reconnect scenarios and memory pressure conditions. Tested by verifying normal TX operation continues after the fix without regressions.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63822", "url": "https://ubuntu.com/security/CVE-2026-63822", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix warning when unbinding If there is an error during some initialization related to firmware, the buffers dp->tx_ring[i].tx_status are released. However this is released again when the device is unbinded (ath11k_pci), and we get: WARNING: CPU: 0 PID: 6231 at mm/slub.c:4368 free_large_kmalloc+0x57/0x90 Call Trace: free_large_kmalloc ath11k_dp_free ath11k_core_deinit ath11k_pci_remove ... The issue is always reproducible from a VM because the MSI addressing initialization is failing. In order to fix the issue, just set the buffers to NULL after releasing in order to avoid the double free.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63823", "url": "https://ubuntu.com/security/CVE-2026-63823", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: keys: Pin request_key_auth payload in instantiate paths A: request_key() B: KEYCTL_INSTANTIATE_IOV ================ ========================= create auth key store rka in auth key wait for helper get auth key load rka from auth key copy user payload sleep on #PF helper completed detach and free rka destroy auth key wake up use rka->target_key **USE-AFTER-FREE** Give request_key_auth payloads a refcount. Take a payload reference while authkey->sem stabilizes the payload and revocation state. Hold that reference across the instantiate and reject paths. Drop the auth key owning reference from revoke and destroy. [jarkko: Replaced the first two paragraphs of text with an actual concurrency scenario.]", "cve_priority": "high", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63824", "url": "https://ubuntu.com/security/CVE-2026-63824", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KEYS: fix overflow in keyctl_pkey_params_get_2() The length for the internal output buffer is calculated incorrectly, which can result overflow when a too small buffer is provided. Fix the bug by allocating internal output with the size of the maximum length of the cryptographic primitive instead of caller provided size.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63826", "url": "https://ubuntu.com/security/CVE-2026-63826", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: fix use-after-free in store_modes() store_modes() replaces a framebuffer's modelist with modes from userspace. On success it frees the old modelist with fb_destroy_modelist(). Two fields still point into that freed list. One pointer is fb_display[i].mode, the mode a console is using. fbcon_new_modelist() moves these pointers to the new list. It only does so for consoles still mapped to the framebuffer. An unmapped console is skipped and keeps its stale pointer. Unbinding fbcon, for example, sets con2fb_map[i] to -1 but leaves fb_display[i].mode set. An FBIOPUT_VSCREENINFO ioctl with FB_ACTIVATE_INV_MODE later reaches fbcon_mode_deleted(). That function reads the stale fb_display[i].mode through fb_mode_is_equal(). The read is a use-after-free. The other pointer is fb_info->mode, the current mode. It is set through the mode sysfs attribute. store_modes() does not update fb_info->mode, so it is left pointing into the freed list. show_mode(), the attribute's read handler, dereferences the stale fb_info->mode through mode_string(). The read is a use-after-free. Clear both pointers before freeing the list. Commit a1f305893074 (\"fbcon: Set fb_display[i]->mode to NULL when the mode is released\") added the helper fbcon_delete_modelist(). It clears every fb_display[i].mode that points into a given list. So far it is called only from the unregister path. Call it from store_modes() too, and set fb_info->mode to NULL.", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-64254", "url": "https://ubuntu.com/security/CVE-2026-64254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NTB: epf: Avoid pci_iounmap() with offset when PEER_SPAD and CONFIG share BAR When BAR_PEER_SPAD and BAR_CONFIG share one PCI BAR, the module teardown path ends up calling pci_iounmap() on the same iomem with some offset, which is unnecessary and triggers a kernel warning like the following: Trying to vunmap() nonexistent vm area (0000000069a5ffe8) WARNING: mm/vmalloc.c:3470 at vunmap+0x58/0x68, CPU#5: modprobe/2937 [...] Call trace: vunmap+0x58/0x68 (P) iounmap+0x34/0x48 pci_iounmap+0x2c/0x40 ntb_epf_pci_remove+0x44/0x80 [ntb_hw_epf] pci_device_remove+0x48/0xf8 device_remove+0x50/0x88 device_release_driver_internal+0x1c8/0x228 driver_detach+0x50/0xb0 bus_remove_driver+0x74/0x100 driver_unregister+0x34/0x68 pci_unregister_driver+0x34/0xa0 ntb_epf_pci_driver_exit+0x14/0xfe0 [ntb_hw_epf] [...] Fix it by unmapping only when PEER_SPAD and CONFIG use difference bars.", "cve_priority": "medium", "cve_public_date": "2026-07-24 16:16:00 UTC" }, { "cve": "CVE-2026-63827", "url": "https://ubuntu.com/security/CVE-2026-63827", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: apparmor: fix use-after-free in rawdata dedup loop aa_replace_profiles() walks ns->rawdata_list to dedup the incoming policy blob against entries already attached to existing profiles. Per the kernel-doc on struct aa_loaddata, list membership does not hold a reference: profiles hold pcount, and when the last pcount drops, do_ploaddata_rmfs() is queued on a workqueue that takes ns->lock and removes the entry. Between dropping the last pcount and the workqueue running, an entry remains on the list with pcount == 0. aa_get_profile_loaddata() is an unconditional kref_get() on pcount, so when the dedup loop hits such an entry, refcount hardening reports refcount_t: addition on 0; use-after-free. inside aa_replace_profiles(), and the poisoned counter then trips \"saturated\" and \"underflow\" warnings on the subsequent uses of the same loaddata. Before commit a0b7091c4de4 (\"apparmor: fix race on rawdata dereference\") the dedup path used a get_unless_zero-style helper on a single counter, so the existing \"if (tmp)\" guard was meaningful. The split-refcount refactor introduced aa_get_profile_loaddata(), which has plain kref_get() semantics, and the guard quietly became a no-op. Introduce aa_get_profile_loaddata_not0(), matching the existing _not0 convention used by aa_get_profile_not0(), and use it for the rawdata_list dedup lookup so dying entries are skipped. Reproduced on x86_64 with v7.1-rc5 in QEMU+KVM running Ubuntu 24.04 + stress-ng 0.17.06: stress-ng --apparmor 1 --klog-check --timeout 60s Without this patch the three refcount_t warnings fire within a few seconds. With it the same 60 s run is clean. Coverage is a smoke-test only; a longer soak with CONFIG_KASAN, CONFIG_KCSAN and CONFIG_PROVE_LOCKING would be welcome from anyone with the cycles.", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63828", "url": "https://ubuntu.com/security/CVE-2026-63828", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: apparmor: mediate the implicit connect of TCP fast open sendmsg sendmsg()/sendto() with MSG_FASTOPEN is a combination of connect(2) and write(2): it opens the connection in the SYN. apparmor_socket_sendmsg() only checks AA_MAY_SEND, so a profile that grants send but denies connect lets a confined task open an outbound TCP/MPTCP connection that connect(2) would have refused, bypassing connect mediation. Mediate the implicit connect when MSG_FASTOPEN is set and a destination is supplied. Add it to apparmor_socket_sendmsg() (not the shared aa_sock_msg_perm() helper, which recvmsg also uses) and call aa_sk_perm() directly, mirroring the selinux and tomoyo fixes. sk_is_tcp() does not cover MPTCP fast open, so the SOCK_STREAM/IPPROTO_MPTCP arm is explicit.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63830", "url": "https://ubuntu.com/security/CVE-2026-63830", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: skmsg: preserve sg.copy across SG transforms The sk_msg sg.copy bitmap is part of the scatterlist entry ownership state. A set bit tells sk_msg_compute_data_pointers() not to expose the entry through writable BPF ctx->data. This protects entries backed by pages that are not private to the sk_msg, such as splice-backed file page-cache pages. Several sk_msg transform paths move, copy, split, or compact msg->sg.data[] entries without moving the matching sg.copy bit. This can make an externally backed entry arrive at a new slot with a clear copy bit. A later SK_MSG verdict can then expose sg_virt(sge) as writable ctx->data and BPF stores can modify the original page cache. Keep sg.copy synchronized with sg.data[] whenever entries are transferred, shifted, split, or copied into a new sk_msg. Clear the bit when an entry is replaced by a newly allocated private page or freed. This covers the BPF pull/push/pop helpers, sk_msg_shift_left/right(), sk_msg_xfer(), and tls_split_open_record(), including the partial tail entry created during TLS open-record splitting.", "cve_priority": "low", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63831", "url": "https://ubuntu.com/security/CVE-2026-63831", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mac802154: llsec: add skb_cow_data() before in-place crypto llsec_do_encrypt_unauth(), llsec_do_encrypt_auth(), llsec_do_decrypt_unauth(), and llsec_do_decrypt_auth() all perform in-place cryptographic transformations on skb data. They build a scatterlist with sg_init_one() pointing into the skb's linear data area and then pass the same scatterlist as both src and dst to the crypto API (e.g. crypto_skcipher_encrypt/decrypt, crypto_aead_encrypt/decrypt). On the RX path, __ieee802154_rx_handle_packet() clones the received skb before handing it to each subscriber via ieee802154_subif_frame(). The cloned skb shares the same underlying data buffer via reference counting. When llsec_do_decrypt() subsequently modifies this shared buffer in place, it corrupts data that other clones -- potentially belonging to other sockets or subsystems -- still reference. On the TX path, similar data sharing can occur when an skb's head has been cloned (skb_cloned() returns true). The fix is to call skb_cow_data() before performing any in-place crypto operation. skb_cow_data() ensures that the skb's data area is not shared: if the skb head is cloned or the data spans multiple fragments, it copies the data into a private buffer that can be safely modified in place. This is the same pattern used by: - ESP (net/ipv4/esp4.c, net/ipv6/esp6.c) - MACsec (drivers/net/macsec.c) - WireGuard (drivers/net/wireguard/receive.c) - TIPC (net/tipc/crypto.c) Without this guard, in-place crypto on shared skb data leads to: - Silent data corruption of other skb clones - Use-after-free when the crypto API scatterwalk writes through a page that has already been freed by another clone's kfree_skb() - Kernel crashes under concurrent 802.15.4 traffic with security enabled (KASAN/KMSAN reports slab-use-after-free) Found by 0sec (https://0sec.ai) using automated source analysis.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53361", "url": "https://ubuntu.com/security/CVE-2026-53361", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: af_unix: Set gc_in_progress to true in unix_gc(). Igor Ushakov reported that unix_gc() could run with gc_in_progress being false if the work is scheduled while running: Thread 1 Thread 2 Thread 3 -------- -------- -------- unix_schedule_gc() unix_schedule_gc() `- if (!gc_in_progress) `- if (!gc_in_progress) |- gc_in_progress = true | `- queue_work() | unix_gc() <----------------/ | | |- gc_in_progress = true ... `- queue_work() | | `- gc_in_progress = false | | unix_gc() <---------------------------------------------' | ... /* gc_in_progress == false */ | `- gc_in_progress = false unix_peek_fpl() relies on gc_in_progress not to confuse GC by MSG_PEEK. Let's set gc_in_progress to true in unix_gc().", "cve_priority": "medium", "cve_public_date": "2026-07-04 12:17:00 UTC" }, { "cve": "CVE-2026-63833", "url": "https://ubuntu.com/security/CVE-2026-63833", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: reject direct userspace writes to reserved $LX* xattrs NTFS3 uses $LXUID, $LXGID, $LXMOD and $LXDEV as internal WSL permission metadata and reloads them into i_uid, i_gid and i_mode from ntfs_get_wsl_perm(). Because the empty-prefix xattr handler also lets file owners call setxattr() on these names directly, an unprivileged writer on a writable ntfs3 mount can plant root ownership and S_ISUID on their own file and gain euid 0 after inode reload. Reject direct userspace writes to the reserved $LX* names. Internal ntfs3 metadata updates are unchanged because ntfs_save_wsl_perm() writes them via ntfs_set_ea() directly. [almaz.alexandrovich@paragon-software.com: added an additional check for non privileged users]", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53366", "url": "https://ubuntu.com/security/CVE-2026-53366", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: account for fraggap on the paged allocation path In __ip_append_data(), when the paged-allocation branch is taken, alloclen and pagedlen are computed as \talloclen = fragheaderlen + transhdrlen; \tpagedlen = datalen - transhdrlen; datalen already includes fraggap, but the fraggap bytes carried over from the previous skb are copied into the new skb's linear area at offset transhdrlen by the subsequent skb_copy_and_csum_bits(). The linear area is therefore undersized by fraggap bytes while pagedlen is overstated by the same amount. The non-paged branch sets alloclen to fraglen, which already accounts for fraggap because datalen does. Bring the paged branch in line by adding fraggap to alloclen and subtracting it from pagedlen. After this adjustment, copy no longer collapses to -fraggap on the paged path, so remove the stale comment describing that old arithmetic.", "cve_priority": "medium", "cve_public_date": "2026-07-16 06:16:00 UTC" }, { "cve": "CVE-2026-53362", "url": "https://ubuntu.com/security/CVE-2026-53362", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: account for fraggap on the paged allocation path In __ip6_append_data(), when the paged-allocation branch is taken (MSG_MORE / NETIF_F_SG / large fraglen), alloclen and pagedlen are computed as \talloclen = fragheaderlen + transhdrlen; \tpagedlen = datalen - transhdrlen; datalen already includes fraggap (datalen = length + fraggap). When fraggap is non-zero, this is not the first skb and transhdrlen is zero. The fraggap bytes carried over from the previous skb are copied just past the fragment headers in the new skb's linear area. The linear area is therefore undersized by fraggap bytes while pagedlen is overstated by the same amount, and the copy writes past skb->end into the trailing skb_shared_info. An unprivileged user can trigger this via a UDPv6 socket using MSG_MORE together with MSG_SPLICE_PAGES. The bad accounting was introduced by commit 773ba4fe9104 (\"ipv6: avoid partial copy for zc\"). Before commit ce650a166335 (\"udp6: Fix __ip6_append_data()'s handling of MSG_SPLICE_PAGES\"), the negative copy value caused -EINVAL to be returned. That later commit allowed MSG_SPLICE_PAGES to proceed in this case, making the corruption triggerable. The non-paged branch sets alloclen to fraglen, which already accounts for fraggap because datalen does. Bring the paged branch in line by adding fraggap to alloclen and subtracting it from pagedlen. After this adjustment, copy no longer collapses to -fraggap on the paged path, so remove the stale comment describing that old arithmetic. Since a negative copy is no longer expected for a valid MSG_SPLICE_PAGES case, remove the MSG_SPLICE_PAGES exception from the negative copy check.", "cve_priority": "high", "cve_public_date": "2026-07-04 12:17:00 UTC" }, { "cve": "CVE-2026-63834", "url": "https://ubuntu.com/security/CVE-2026-63834", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: tp_meter: restrict number of unacked list entries When the unacked_list is unbound, an attacker could send messages with small lengths and appropriated seqno + gaps to force the receiver to allocate more and more unacked_list entries. And the end either causing an out-of-memory situation or increase the management overhead for the (large) list that significant portions of CPU cycles are wasted in searching through the list. When limiting the list to a specific number, it is important to still correctly add a new entry to the list. But if the list became larger than the limit, the last entry of the list (with the highest seqno) must be dropped to still allow the earlier seqnos to finish and therefore to continue the process. Otherwise, the process might get stuck with too high seqnos which are not handled by batadv_tp_ack_unordered().", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63835", "url": "https://ubuntu.com/security/CVE-2026-63835", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: v: prevent OGM aggregation on disabled hardif When an interface gets disabled, the worker is correctly disabled by batadv_hardif_disable_interface() -> ... -> batadv_v_ogm_iface_disable(). In this process, the skb aggr_list is also freed. But batadv_v_ogm_send_meshif() can still queue new skbs (via batadv_v_ogm_queue_on_if()) to the aggr_list. This will only stop after all cores can no longer find the RCU protected list of hard interfaces. These queued skbs will never be freed or consumed by batadv_v_ogm_aggr_work. The batadv_v_ogm_iface_disable() function must block batadv_v_ogm_queue_on_if() to avoid leak of skbs.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63836", "url": "https://ubuntu.com/security/CVE-2026-63836", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: tp_meter: avoid divide-by-zero for dec_cwnd The cwnd is always MSS <= cwnd <= 0x20000000. But the calculation in batadv_tp_update_cwnd() assumes unsigned 32 bit arithmetics. ((mss * 8) ** 2) / (cwnd * 8) In case cwnd is actually 0x20000000, it will be shifted by 3 bit to the left end up at 0x100000000 or U32_MAX + 1. It will therefore wrap around and be 0 - resulting in: ((mss * 8) ** 2) / 0 This is of course invalid and cannot be calculated. The calculation should must be simplified to avoid this overflow: (mss ** 2) * 8 / cwnd It will keep the precision enhancement from the scaling (by 8) but avoid the overflow in the divisor. In theory, there could still be an overflow in the dividend. It is at the moment fixed to BATADV_TP_PLEN in batadv_tp_recv_ack() - so it is not an imminent problem. But allowing it to use the whole u32 bit range, would mean that it can still use up to 67 bits. To keep this calculation safe for 32 bit arithmetic, mss must never use more than floor((32 - 3) / 2) bits - or in other words: must never be larger than 16383.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-63807", "url": "https://ubuntu.com/security/CVE-2026-63807", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: x86/mmu: Ensure hugepage is in by slot before checking max mapping level When recovering hugepages in the shadow MMU, verify that the base gfn of the shadow page is actually contained within the target memslot, *before* querying the max mapping level given the shadow page's gfn. Failure to pre-check the validity of the gfn can lead to an out-of-bounds access to the slot's lpage_info (which typically manifests as a host #PF because the lpage_info is vmalloc'd) if the guest creates a hugepage mapping (in its PTEs) that extends \"below\" the bounds of a memslot. When faulting in memory for a guest, and the size of the guest mapping is greater than KVM's (current) max mapping, then KVM will create a \"direct\" shadow page (direct in that there are no gPTEs to shadow, and so the target gfn is a direct calculation given the base gfn of the shadow page). The hugepage recovery flow looks for such direct shadow pages, as forcing 4KiB mappings when dirty logging generates the guest > host mapping size case. When the 4KiB restriction is lifted, then KVM can replace the shadow page with a hugepage. But if KVM originally used a smaller mapping than the guest because the range of memory covered by the guest hugepage exceeds the bounds of a memslot, then KVM will link a direct shadow page with a gfn that is outside the bounds of the memslot being used to fault in memory. The rmap entry added for the leaf mapping is correct and within bounds, but the gfn of the leaf SPTE's parent shadow page will be out of bounds. BUG: unable to handle page fault for address: ffffc90000806ffc #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 100000067 P4D 100000067 PUD 1002a7067 PMD 10612f067 PTE 0 Oops: Oops: 0000 [#1] SMP CPU: 13 UID: 1000 PID: 757 Comm: mmu_stress_test Not tainted 7.1.0-rc1-48ce1e26eace-x86_pir_to_irr_comments-vm #341 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:kvm_mmu_max_mapping_level+0x79/0x2b0 [kvm] Call Trace: kvm_mmu_recover_huge_pages+0x21b/0x320 [kvm] kvm_set_memslot+0x1ee/0x590 [kvm] kvm_set_memory_region.part.0+0x3a1/0x4d0 [kvm] kvm_vm_ioctl+0x9bf/0x15d0 [kvm] __x64_sys_ioctl+0x8a/0xd0 do_syscall_64+0xb7/0xbb0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f21c0f1a9bf Don't bother pre-checking the bounds of the potential hugepage, i.e. don't check that e.g. sp->gfn + KVM_PAGES_PER_HPAGE(sp->role.level + 1) is also within the memslot, as the checks performed by kvm_mmu_max_mapping_level() are a superset of the basic bounds checks. I.e. pre-checking the full range would be a dubious micro-optimization.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53381", "url": "https://ubuntu.com/security/CVE-2026-53381", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtiofs: fix UAF on submount umount iput() called from fuse_release_end() can Oops if the super block has already been destroyed. Normally this is prevented by waiting for num_waiting to go down to zero before commencing with super block shutdown. This only works, however, for the last submount instance, as the wait counter is per connection, not per superblock. Revert to using synchronous release requests for the auto_submounts case, which is virtiofs only at this time.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53382", "url": "https://ubuntu.com/security/CVE-2026-53382", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: vidtv: fix NULL pointer dereference in vidtv_mux_push_si syzbot reported a general protection fault in vidtv_psi_ts_psi_write_into [1]. vidtv_mux_get_pid_ctx() can return NULL, but vidtv_mux_push_si() does not check for this before dereferencing the returned pointer to access the continuity counter. This leads to a general protection fault when accessing a near-NULL address. The root cause is that vidtv_mux_pid_ctx_init() does not check the return value of vidtv_mux_create_pid_ctx_once() for PMT section PIDs. If the allocation fails, the PID context is never created, but init returns success. The subsequent vidtv_mux_push_si() call then gets NULL from vidtv_mux_get_pid_ctx() and crashes. Fix both the root cause (add error check in vidtv_mux_pid_ctx_init for PMT PIDs) and add defensive NULL checks in vidtv_mux_push_si for all vidtv_mux_get_pid_ctx() calls. [1] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] Workqueue: events vidtv_mux_tick RIP: 0010:vidtv_psi_ts_psi_write_into+0x54a/0xbc0 drivers/media/test-drivers/vidtv/vidtv_psi.c:197 Call Trace: vidtv_psi_table_header_write_into drivers/media/test-drivers/vidtv/vidtv_psi.c:799 [inline] vidtv_psi_pmt_write_into+0x3b2/0xa70 drivers/media/test-drivers/vidtv/vidtv_psi.c:1231 vidtv_mux_push_si+0x932/0xe80 drivers/media/test-drivers/vidtv/vidtv_mux.c:196 vidtv_mux_tick+0xe9b/0x1480 drivers/media/test-drivers/vidtv/vidtv_mux.c:408", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53383", "url": "https://ubuntu.com/security/CVE-2026-53383", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: reject non-VALID session in compound request branch smb2_check_user_session() takes a shortcut for any operation that is not the first in a COMPOUND request: it reuses work->sess (the session bound by the first operation) and validates only the SessionId, then returns \"valid\". It never re-checks work->sess->state == SMB2_SESSION_VALID, and a SessionId of 0xFFFFFFFFFFFFFFFF (ULLONG_MAX, the MS-SMB2 related-operation value) skips even the id comparison. The standalone path (ksmbd_session_lookup_all() plus the SESSION_SETUP state machine) does enforce the VALID state; the compound branch bypasses all of it. A SESSION_SETUP carrying only an NTLM Type-1 (NtLmNegotiate) blob publishes a fresh SMB2_SESSION_IN_PROGRESS session whose sess->user is still NULL (->user is assigned later, by ntlm_authenticate()). Used as operation 1 of a COMPOUND with operation 2 = TREE_CONNECT (related, SessionId=ULLONG_MAX, \\\\host\\IPC$), the tree-connect then runs on that IN_PROGRESS session and reaches ksmbd_ipc_tree_connect_request(), which dereferences user_name(sess->user) with sess->user == NULL (transport_ipc.c:687/701/704) -> remote NULL-pointer dereference and a kernel Oops that wedges the ksmbd worker for all clients. Reject any non-first compound operation that lands on a session which is not SMB2_SESSION_VALID, mirroring the validity the standalone lookup path enforces. SESSION_SETUP itself legitimately runs on an IN_PROGRESS session, but it is never carried as a non-first compound operation, so multi-leg authentication is unaffected by this check.", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53385", "url": "https://ubuntu.com/security/CVE-2026-53385", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vc_screen: fix null-ptr-deref in vcs_notifier() during concurrent vcs_write A KASAN null-ptr-deref was observed in vcs_notifier(): BUG: KASAN: null-ptr-deref in vcs_notifier+0x98/0x130 Read of size 2 at addr qmp_cmd_name: qmp_capabilities, arguments: {} The issue is a race condition in vcs_write(). When the console_lock is temporarily dropped (to copy data from userspace), the vc_data pointer obtained from vcs_vc() may become stale. After re-acquiring the lock, vcs_vc() is called again to re-validate the pointer. If the vc has been deallocated in the meantime, vcs_vc() returns NULL, and the while loop breaks (with written > 0). However, after the loop, vcs_scr_updated(vc) is still called with the now-NULL vc pointer, leading to a null pointer dereference in the notifier chain (vcs_notifier dereferences param->vc). Fix this by adding a NULL check for vc before calling vcs_scr_updated().", "cve_priority": "medium", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53388", "url": "https://ubuntu.com/security/CVE-2026-53388", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: re-lock request before replacing page cache folio fuse_try_move_folio() unlocks the request on entry but does not re-lock it on the success path. This means fuse_chan_abort() can end the request and free the fuse_io_args (eg fuse_readpages_end()) while the subsequent copy chain logic after fuse_try_move_folio() accesses the fuse_io_args, leading to use-after-free issues. Fix this by calling lock_request() before replace_page_cache_folio(). This ensures the request is locked on the success path which will prevent the fuse_io_args from being freed while the later copying logic runs, and also ensures that the ap->folios[i]->mapping is never null since ap->folios[i] will always point to the newfolio after replace_page_cache_folio().", "cve_priority": "high", "cve_public_date": "2026-07-19 12:16:00 UTC" }, { "cve": "CVE-2026-53157", "url": "https://ubuntu.com/security/CVE-2026-53157", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: phonet: free phonet_device after RCU grace period phonet_device_destroy() removes a phonet_device from the per-net device list with list_del_rcu(), but frees it immediately. RCU readers walking the same list can still hold a pointer to the object after it has been removed, leading to a slab-use-after-free. Use kfree_rcu(), matching the lifetime rule already used by phonet_address_del() for the same object type.", "cve_priority": "low", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2026-53163", "url": "https://ubuntu.com/security/CVE-2026-53163", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: locking/rtmutex: Skip remove_waiter() when waiter is not enqueued syzbot triggered the following splat in remove_waiter() via FUTEX_CMP_REQUEUE_PI: KASAN: null-ptr-deref in range [0x0000000000000a88-0x0000000000000a8f] class_raw_spinlock_constructor remove_waiter+0x159/0x1200 kernel/locking/rtmutex.c:1561 rt_mutex_start_proxy_lock+0x103/0x120 futex_requeue+0x10e4/0x20d0 __x64_sys_futex+0x34f/0x4d0 task_blocks_on_rt_mutex() does not arm the waiter upon deadlock detection, leaving waiter->task nil, where 3bfdc63936dd (\"rtmutex: Use waiter::task instead of current in remove_waiter()\") made this fatal. Furthermore, rt_mutex_start_proxy_lock() should not be calling into remove_waiter() upon a successfully grabbing the rtmutex. 1a1fb985f2e2 (\"futex: Handle early deadlock return correctly\"), moved the remove_waiter() out of __rt_mutex_start_proxy_lock() (where 'ret' was only ever 0 or < 0) into the wrapper. Tighten this check to account for try_to_take_rt_mutex().", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" }, { "cve": "CVE-2025-23131", "url": "https://ubuntu.com/security/CVE-2025-23131", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dlm: prevent NPD when writing a positive value to event_done do_uevent returns the value written to event_done. In case it is a positive value, new_lockspace would undo all the work, and lockspace would not be set. __dlm_new_lockspace, however, would treat that positive value as a success due to commit 8511a2728ab8 (\"dlm: fix use count with multiple joins\"). Down the line, device_create_lockspace would pass that NULL lockspace to dlm_find_lockspace_local, leading to a NULL pointer dereference. Treating such positive values as successes prevents the problem. Given this has been broken for so long, this is unlikely to break userspace expectations.", "cve_priority": "medium", "cve_public_date": "2025-04-16 15:16:00 UTC" }, { "cve": "CVE-2026-46252", "url": "https://ubuntu.com/security/CVE-2026-46252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regulator: core: fix locking in regulator_resolve_supply() error path If late enabling of a supply regulator fails in regulator_resolve_supply(), the code currently triggers a lockdep warning: WARNING: drivers/regulator/core.c:2649 at _regulator_put+0x80/0xa0, CPU#6: kworker/u32:4/596 ... Call trace: _regulator_put+0x80/0xa0 (P) regulator_resolve_supply+0x7cc/0xbe0 regulator_register_resolve_supply+0x28/0xb8 as the regulator_list_mutex must be held when calling _regulator_put(). To solve this, simply switch to using regulator_put(). While at it, we should also make sure that no concurrent access happens to our rdev while we clear out the supply pointer. Add appropriate locking to ensure that. While the code in question will be removed altogether in a follow-up commit, I believe it is still beneficial to have this corrected before removal for future reference.", "cve_priority": "low", "cve_public_date": "2026-06-03 18:16:00 UTC" }, { "cve": "CVE-2026-52928", "url": "https://ubuntu.com/security/CVE-2026-52928", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: af_unix: Reject SIOCATMARK on non-stream sockets SIOCATMARK reports whether the receive queue is at the urgent mark for MSG_OOB. In AF_UNIX, MSG_OOB is supported only for SOCK_STREAM sockets. SOCK_DGRAM and SOCK_SEQPACKET reject MSG_OOB in sendmsg() and recvmsg(), so they should not support SIOCATMARK either. Return -EOPNOTSUPP for non-stream sockets before checking the receive queue.", "cve_priority": "medium", "cve_public_date": "2026-06-24 08:16:00 UTC" }, { "cve": "CVE-2026-43010", "url": "https://ubuntu.com/security/CVE-2026-43010", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Reject sleepable kprobe_multi programs at attach time kprobe.multi programs run in atomic/RCU context and cannot sleep. However, bpf_kprobe_multi_link_attach() did not validate whether the program being attached had the sleepable flag set, allowing sleepable helpers such as bpf_copy_from_user() to be invoked from a non-sleepable context. This causes a \"sleeping function called from invalid context\" splat: BUG: sleeping function called from invalid context at ./include/linux/uaccess.h:169 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1787, name: sudo preempt_count: 1, expected: 0 RCU nest depth: 2, expected: 0 Fix this by rejecting sleepable programs early in bpf_kprobe_multi_link_attach(), before any further processing.", "cve_priority": "medium", "cve_public_date": "2026-05-01 15:16:00 UTC" }, { "cve": "CVE-2026-53325", "url": "https://ubuntu.com/security/CVE-2026-53325", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: agp/amd64: Fix broken error propagation in agp_amd64_probe() A NULL pointer dereference was observed in the AMD64 AGP driver when running in a virtualized environment (e.g. qemu/kvm) without a physical AMD northbridge. The crash occurs in amd64_fetch_size() when attempting to dereference the pointer returned by node_to_amd_nb(0). The root cause of this crash is broken error propagation in agp_amd64_probe(): When no AMD northbridges are found, cache_nbs() correctly returns -ENODEV. However, the probe function erroneously checks the return value against exactly -1, rather than < 0. As a result, the hardware absence error is masked, allowing the driver to improperly proceed with initialization. It eventually calls agp_add_bridge(), which invokes amd64_fetch_size(). Since the hardware does not exist, node_to_amd_nb(0) returns NULL, leading to a General Protection Fault (GPF) when accessing its ->misc member. Fix the issue by correcting the error check in agp_amd64_probe() to abort properly when cache_nbs() returns any negative error code. This prevents the driver from erroneously proceeding without hardware, thereby avoiding the subsequent NULL pointer dereference at its source.", "cve_priority": "medium", "cve_public_date": "2026-06-29 06:16:00 UTC" }, { "cve": "CVE-2026-64188", "url": "https://ubuntu.com/security/CVE-2026-64188", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: qualcomm: rmnet: fix endpoint use-after-free in rmnet_dellink() rmnet_dellink() removes the endpoint from the hash table with hlist_del_init_rcu() and then immediately frees it with kfree(). However, RCU readers on the receive path (rmnet_rx_handler -> __rmnet_map_ingress_handler) may still hold a reference to the endpoint and dereference ep->egress_dev after the memory has been freed. The endpoint is a kmalloc-32 object, and the stale read at offset 8 corresponds to the egress_dev pointer. BUG: unable to handle page fault for address: ffffffffde942eef Oops: 0002 [#1] SMP NOPTI CPU: 1 UID: 0 PID: 137 Comm: poc_write Not tainted 7.0.0+ #4 PREEMPTLAZY RIP: 0010:rmnet_vnd_rx_fixup (rmnet_vnd.c:27) Call Trace: __rmnet_map_ingress_handler (rmnet_handlers.c:48 rmnet_handlers.c:101) rmnet_rx_handler (rmnet_handlers.c:129 rmnet_handlers.c:235) __netif_receive_skb_core.constprop.0 (net/core/dev.c:6096) __netif_receive_skb_one_core (net/core/dev.c:6208) netif_receive_skb (net/core/dev.c:6467) tun_get_user (drivers/net/tun.c:1955) tun_chr_write_iter (drivers/net/tun.c:2003) vfs_write (fs/read_write.c:688) ksys_write (fs/read_write.c:740) Add an rcu_head field to struct rmnet_endpoint and replace kfree() with kfree_rcu() so the endpoint memory remains valid through the RCU grace period. Also remove the rmnet_vnd_dellink() call and inline only the nr_rmnet_devs decrement, since rmnet_vnd_dellink() would set ep->egress_dev to NULL during the grace period, creating a data race with lockless readers.", "cve_priority": "high", "cve_public_date": "2026-07-20 17:18:00 UTC" }, { "cve": "CVE-2026-64191", "url": "https://ubuntu.com/security/CVE-2026-64191", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: stub: Reject I2C block transfers with invalid length The I2C_SMBUS_I2C_BLOCK_DATA case in stub_xfer() uses data->block[0] as the transfer length. The existing check only clamps it to avoid overrunning the chip->words[256] register array, but does not validate it against I2C_SMBUS_BLOCK_MAX (32), which is the limit of the union i2c_smbus_data.block buffer (34 bytes total). The driver is a development/test tool (CONFIG_I2C_STUB=m, not built by default) that must be loaded with a chip_addr= parameter. A local user with access to /dev/i2c-* can issue an I2C_SMBUS ioctl with I2C_SMBUS_I2C_BLOCK_DATA and data->block[0] > 32, causing stub_xfer() to read or write past the end of the union i2c_smbus_data.block buffer: BUG: KASAN: stack-out-of-bounds in stub_xfer (drivers/i2c/i2c-stub.c:223) Read of size 1 at addr ffff88800abcfd92 by task exploit/81 Call Trace: stub_xfer (drivers/i2c/i2c-stub.c:223) __i2c_smbus_xfer (drivers/i2c/i2c-core-smbus.c:593) i2c_smbus_xfer (drivers/i2c/i2c-core-smbus.c:536) i2cdev_ioctl_smbus (drivers/i2c/i2c-dev.c:391) i2cdev_ioctl (drivers/i2c/i2c-dev.c:478) __x64_sys_ioctl (fs/ioctl.c:583) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) The bug exists because i2c-stub implements .smbus_xfer directly, bypassing the I2C_SMBUS_BLOCK_MAX validation in i2c_smbus_xfer_emulated(). The I2C_SMBUS_BLOCK_DATA case in the same function correctly validates against I2C_SMBUS_BLOCK_MAX, but the I2C_SMBUS_I2C_BLOCK_DATA case does not. Fix by rejecting transfers with data->block[0] == 0 or data->block[0] > I2C_SMBUS_BLOCK_MAX with -EINVAL, consistent with both the I2C_SMBUS_BLOCK_DATA case in the same function and the I2C_SMBUS_I2C_BLOCK_DATA validation in i2c_smbus_xfer_emulated().", "cve_priority": "high", "cve_public_date": "2026-07-20 17:18:00 UTC" }, { "cve": "CVE-2026-53327", "url": "https://ubuntu.com/security/CVE-2026-53327", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: debugobjects: Do not fill_pool() if pi_blocked_on On RT enabled kernels, fill_pool() ends up calling rtlock_lock(), which asserts if current::pi_blocked_on is set, because a task can obviously only block on one lock as otherwise the priority inheritenace chain gets corrupted. Prevent this by expanding the conditional to take current::pi_blocked_on into account.", "cve_priority": "medium", "cve_public_date": "2026-07-01 14:16:00 UTC" }, { "cve": "CVE-2026-52909", "url": "https://ubuntu.com/security/CVE-2026-52909", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ip6_vti: set netns_immutable on the fallback device. john1988 and Noam Rathaus reported that vti6_init_net() does not set the netns_immutable flag on the per-netns fallback tunnel device (ip6_vti0). Other similar tunnel drivers (like ip6_tunnel, sit, ip6_gre, and ip_tunnel) correctly set this flag during their fallback device initialization to prevent them from being moved to another network namespace.", "cve_priority": "high", "cve_public_date": "2026-06-19 15:16:00 UTC" }, { "cve": "CVE-2026-53167", "url": "https://ubuntu.com/security/CVE-2026-53167", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: limit FUSE_NOTIFY_RETRIEVE to uptodate folios FUSE_NOTIFY_RETRIEVE must be limited to uptodate folios; !uptodate folios can contain uninitialized data. Since FUSE_NOTIFY_RETRIEVE is intended to only return data that is already in the page cache and not wait for data from the FUSE daemon, treat !uptodate folios as if they weren't present. This only has security impact on systems that don't enable automatic zero-initialization of all page allocations via CONFIG_INIT_ON_ALLOC_DEFAULT_ON or init_on_alloc=1.", "cve_priority": "medium", "cve_public_date": "2026-06-25 09:16:00 UTC" } ], "log": [ "", " * noble/linux: 6.8.0-147.147 -proposed tracker (LP: #2168142)", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026)", " - platform/x86/intel-uncore-freq: Fix current_freq_khz after CPU hotplug", " - selftests/bpf: Add tests for ld_{abs,ind} failure path in subprogs", " - drm/virtio: fix deadlock in display_info_cb by removing hotplug from", " dequeue worker", " - mtd: mtdswap: remove debugfs stats file on teardown", " - seqlock: Cure some more scoped_seqlock() optimization fails", " - seqlock: Allow KASAN to fail optimizing", " - seqlock: Allow UBSAN_ALIGNMENT to fail optimizing", " - xprtrdma: Clear receive-side ownership pointers on release", " - Input: ims-pcu - fix logic error in packet reset", " - arm64: tegra: Fix CPU compatible string to cortex-a78ae on Tegra234", " - mtd: nand: mtk-ecc: stop on ECC idle timeouts", " - RDMA/cma: Fix hardware address comparison length in netevent callback", " - RDMA/umem: Add support for creating pinned DMABUF umem with a given dma", " device", " - RDMA/umem: Introduce an option to revoke DMABUF umem", " - RDMA/umem: Add ib_umem_dmabuf_get_pinned_and_lock helper", " - RDMA/umem: Move umem dmabuf revoke logic into helper function", " - RDMA/umem: Add pinned revocable dmabuf import interface", " - RDMA/umem: Add helpers for umem dmabuf revoke lock", " - RDMA/erdma: initialize ret for empty receive WR lists", " - RDMA/hns: Fix potential integer overflow in mhop hem cleanup", " - selftests/alsa: Fix memory leak in find_controls error path", " - RDMA/irdma: Prevent overflows in memory contiguity checks", " - wifi: nl80211: validate nested MBSSID IE blobs", " - wifi: cfg80211: validate PMSR measurement type data", " - wifi: cfg80211: reject unsupported PMSR FTM location requests", " - ASoC: meson: aiu: fifo-spdif: soft reset the S/PDIF datapath on", " start/stop", " - ASoC: amd: ps: fix wrong ACP version string in pci_request_regions()", " - ASoC: cs42l43: Correct report for forced microphone jack", " - ASoC: tas2562: fix deprecated 'shut-down' GPIO always cleared after", " lookup", " - firmware: arm_scmi: Rate-limit queue-full warnings in IRQ context", " - ata: sata_dwc_460ex: use platform_get_irq()", " - ata: sata_dwc_460ex: fix clear_interrupt_bit() clearing all pending", " interrupts", " - ALSA: usb-audio: Skip DSD quirk for Musical Fidelity M6s DAC", " - drm/i915/gt: use correct selftest config symbol", " - sched/vtime: Get rid of generic vtime_task_switch() implementation", " - powerpc/time: Prepare to stop elapsing in dynticks-idle", " - powerpc/vtime: Initialize starttime at boot for native accounting", " - can: j1939: fix lockless local-destination check", " - drm/i915/selftests: Fix GT PM sort comparators", " - USB: storage: add NO_ATA_1X quirk for Longmai USB Key", " - usb: chipidea: fix usage_count leak when autosuspend_delay is negative", " - USB: gadget: snps-udc: fix device name leak on probe failure", " - USB: gadget: fsl-udc: fix device name leak on probe failure", " - USB: serial: ftdi_sio: add support for E+H FXA291", " - USB: serial: keyspan_pda: fix data loss on receive throttling", " - USB: serial: option: add TDTECH MT5710-CN", " - crypto: rsa-pkcs1pad: Don't WARN on an empty digest", " - RISC-V: KVM: Serialize virtual interrupt pending state updates", " - usb: xhci-pci: Limit VIA VL805 DMA addressing to 36 bits", " - wifi: ath11k: Flush the posted write after writing to", " PCIE_SOC_GLOBAL_RESET", " - wifi: ath12k: Flush the posted write after writing to", " PCIE_SOC_GLOBAL_RESET", " - btrfs: declare btrfs_ioctl_search_args_v2::buf as __u8", " - ASoC: bt-sco: fix duplicate DAPM widget names for wideband DAI", " - ASoC: cs35l56: Don't use devres to unregister component", " - ASoC: cs35l56: Fix potential probe() deadlock", " - ASoC: cs35l56: Use complete_all() to signal init_completion", " - wifi: iwlwifi: mvm: validate SAR GEO response payload size", " - wifi: iwlwifi: mvm: fix read in wake packet notification handler", " - hwmon: (asus-ec-sensors) fix looping over banks while reading from EC", " - hwmon: (asus-ec-sensors) fix EC read intervals", " - hwmon: (asus-ec-sensors) add missed handle for ENOMEM", " - wifi: mac80211: recalculate TIM when a station enters power save", " - pds_core: reject component parameter in legacy firmware update", " - amd-xgbe: fix MAC_AUTO_SW handling in CL37 AN", " - pds_core: yield the CPU while waiting for the adminq to drain", " - pds_core: order completion reads after the ownership check", " - pds_core: check for workqueue allocation failure", " - tls: device: push pending open record on splice EOF", " - selftest: af_unix: Add Kconfig file.", " - selftests: af_unix: add USER_NS config", " - selftests: openvswitch: add config file", " - amt: make the head writable before rewriting the L2 header", " - net: bridge: vlan: fix vlan range dumps starting with pvid", " - net: dpaa: fix mode setting", " - iomap: correct the range of a partial dirty clear", " - net: stmmac: fix l3l4 filter rejecting unsupported offload requests", " - net: stmmac: reset residual action in L3L4 filters on delete", " - net: stmmac: enable the MAC on link up for all supported speeds", " - octeontx2-vf: set TC flower flag on MCAM entry allocation", " - ipv4: icmp: fill flow parameters in icmp_route_lookup decoy lookup", " - ppp: use IFF_NO_QUEUE in virtual interfaces", " - ppp: convert to percpu netstats", " - ppp: enable TX scatter-gather", " - ppp: annotate data races in ppp_generic", " - hinic: remove unused ethtool RSS user configuration buffers", " - net/mlx5: E-Switch, fix zero num_dest in prio_tag egress vlan rule", " - net/mlx5e: Report zero bandwidth for non-ETS traffic classes", " - net/mlx5e: Reject unsupported CB Shaper TSA in ETS validation", " - net: ipv6: fix dif and sdif mismatch in raw6_icmp_error", " - ice: fix LAG recipe to profile association", " - drm/rockchip: cdn-dp: add missing check in cdn_dp_config_video()", " - drm/amdgpu/uvd: Fix forcing MSG, FB BOs into VCPU segment when it isn't", " at 0 (v2)", " - drm/amdgpu/uvd: Place VCPU BO only in VRAM for UVD 4.x and older", " - drm/amdgpu: Fix amdgpu_bo_move() when old_mem and new_mem are both GTT", " - drm/nouveau/acr: fix missing nvkm_done() in error path of", " nvkm_acr_oneinit()", " - drm/radeon: fix r100_copy_blit for large BOs", " - drm/amd/display: Handle struct drm_plane_state.ignore_damage_clips", " - drm/amdgpu: Fix VFCT bus number matching with soft filter", " - drm/amd/pm/ci: Don't disable MCLK DPM on Bonaire 0x6658 (R7 260X)", " - media: aspeed: fix missing of_reserved_mem_device_release() on probe", " failure", " - media: cec: seco: unregister adapter on IR probe failure", " - media: cedrus: clean up media device on probe failure", " - media: cedrus: Fix missing cleanup in error path", " - media: marvell-cam: fix missing pci_disable_device() on remove", " - media: nxp: imx8-isi: Clean up already-initialized pipes on probe", " failure", " - media: nxp: imx8-isi: Fix missing v4l2_subdev_cleanup() in pipe init", " error path", " - media: nxp: imx8-isi: Fix scale factor calculation for hardware rounding", " - media: tegra-video: vi: fix invalid u32 return value in format lookup", " - media: v4l2-ctrls-request: add NULL check in", " v4l2_ctrl_request_complete()", " - media: vb2: use ssize_t for vb2_read/vb2_write", " - media: vidtv: fix reference leak on failed device registration", " - media: vimc: fix reference leak on failed device registration", " - media: vivid: add vivid_update_reduced_fps()", " - media: vpif_capture: fix OF node reference imbalance", " - staging: rtl8723bs: fix inverted HT40 secondary channel offset", " - platform/loongarch: laptop: Explicitly reset bl_powered state when", " suspend", " - LoongArch: Fix oops during single-step debugging", " - x86/boot/compressed: Disable jump tables", " - serial: sc16is7xx: implement gpio get_direction() callback", " - tracing/eprobe: Fix exact system name matching in", " eprobe_dyn_event_match()", " - tracing/probes: Avoid temporary buffer truncation in", " trace_probe_match_command_args()", " - tracing/probes: Fix potential underflow in LEN_OR_ZERO macro", " - tracing/probes: Prevent out-of-bounds write in __trace_probe_log_err()", " - arm64: syscall: Ensure saved x0 is kept in-sync with tracer updates", " - Revert \"arm64: syscall: Ensure saved x0 is kept in-sync with tracer", " updates\"", " - mptcp: decrement subflows counter on failed passive join", " - mptcp: only set DATA_FIN when a mapping is present", " - iommu/vt-d: Disallow SVA if page walk is not coherent", " - ice: use READ_ONCE() to access cached PHC time", " - drm/amd/pm: make pp_features read-only when scpm is enabled", " - drm/amd/display: Fix dcn32 DTB DTO update breaking live pixel rate", " sources", " - io_uring/rw: fix missing ERESTARTSYS conversion in read paths", " - net: pcs: xpcs: fix SGMII state reading", " - bpf: drop bpf_lsm_getselfattr from hook list", " - udmabuf: Do not create malformed scatterlists", " - i2c: davinci: Unregister cpufreq notifier on probe failure", " - VFS/audit: introduce kern_path_parent() for audit", " - audit: widen ino fields to u64", " - audit: use 'unsigned int' instead of 'unsigned'", " - ALSA: hda: conexant: Remove mic bias threshold override", " - ALSA: hda: Fix cached processing coefficient verbs", " - rxrpc: Pull out certain app callback funcs into an ops table", " - fbcon: Rename struct fbcon_ops to struct fbcon_par", " - fbcon: Use correct type for vc_resize() return value", " - rxrpc: Don't need barrier for ->tx_bottom and ->acks_hard_ack", " - rxrpc: Use irq-disabling spinlocks between app and I/O thread", " - rxrpc: Fix notification vs call-release vs recvmsg", " - rxrpc: Fix socket notification race", " - vduse: Use fixed 4KB bounce pages for non-4KB page size", " - vduse: remove unused vaddr parameter of vduse_domain_free_coherent", " - vduse: take out allocations from vduse_dev_alloc_coherent", " - octeontx2: Annotate mmio regions as __iomem", " - octeontx2-pf: clear stale mailbox IRQ state before request_irq()", " - octeontx2-vf: clear stale mailbox IRQ state before request_irq()", " - fbdev/efifb: Replace references to global screen_info by local pointer", " - ASoC: mediatek: mt8192-afe-pcm: Convert to devm_pm_runtime_enable()", " - ASoC: mediatek: mt8192-afe-pcm: Simplify with dev_err_probe()", " - ASoC: mediatek: Use common mtk_afe_pcm_platform with common probe cb", " - ASoC: mediatek: mt8192-afe-pcm: Simplify probe() with local dev variable", " - ASoC: mediatek: mt8183: Check runtime resume during probe", " - netfilter: nft_set_pipapo: use GFP_KERNEL for insertions", " - netfilter: nft_set_pipapo: move prove_locking helper around", " - netfilter: nft_set_pipapo: make pipapo_clone helper return NULL", " - netfilter: nft_set_pipapo: prepare walk function for on-demand clone", " - netfilter: nft_set_pipapo: merge deactivate helper into caller", " - netfilter: nft_set_pipapo: prepare pipapo_get helper for on-demand clone", " - netfilter: nft_set_pipapo: move cloning of match info to insert/removal", " path", " - netfilter: nf_conntrack_sip: remove net variable shadowing", " - netfilter: nf_tables: Remove unused nft_reduce_is_readonly()", " - netfilter: nf_tables: remove register tracking infrastructure", " - NFSD: pass nfsd_file to nfsd_iter_read()", " - sunrpc: allocate a separate bvec array for socket sends", " - SUNRPC: Add helpers to convert xdr_buf byte ranges to scatterlists", " - SUNRPC: Return an error from xdr_buf_to_bvec() on overflow", " - mm/mm_init: fix pageblock migratetype for ZONE_DEVICE compound pages", " - dma: dw-edma: Fix build warning in dw_edma_pcie_probe()", " - dmaengine: dw-edma: Fix confusing cleanup.h syntax", " - platform/x86: dell-smbios: Move request functions for reuse", " - i2c: imx: separate atomic, dma and non-dma use case", " - nfs: remove dead code for the old swap over NFS implementation", " - ovl: use linked upper dentry in copy-up tmpfile", " - bootconfig: do not put quotes on cmdline items unless necessary", " - bootconfig: move xbc_snprint_cmdline() to lib/bootconfig.c", " - bootconfig: fix NULL-pointer arithmetic in xbc_snprint_cmdline()", " - net: ipa: fix SMEM state handle leaks in SMP2P init", " - KVM: x86: Only reset TSC Deadline Timer in apic_timer_expired on KVM_RUN", " - udmabuf: Ensure to perform cache synchronisation in begin_cpu_udmabuf()", " - rxrpc: Disable IRQ, not BH, to take the lock for ->attend_link", " - netfilter: nft_quota: use atomic64_xchg for reset", " - soc: qcom: ice: Allow explicit votes on 'iface' clock for ICE", " - wifi: cfg80211: pass net_device to .set_monitor_channel", " - wifi: cfg80211: define and use wiphy guard", " - wifi: cfg80211: derive S1G beacon TSF from S1G fields", " - riscv: hwprobe: Avoid uninitialized read in hwprobe_get_cpus()", " - drm/xe/wopcm: fix WOPCM size for LNL+", " - smb: move some duplicate definitions to common/cifsglob.h", " - regulator: mt6358: use regmap helper to read fixed LDO calibration", " - netlink: specs: rt-link: convert bridge port flag attributes to u8", " - wifi: mt76: mt7925: extend mt7925_mcu_bss_he_tlv for per-link BSS", " - ovl: fix trusted xattr escape prefix matching", " - drm/tests: shmem: Set DMA mask to 64-bit in drm_gem_shmem", " - dpll: add clock quality level attribute and op", " - net/mlx5: DPLL, Add clock quality level op implementation", " - net/mlx5: Remove newline at the end of a netlink error message", " - net/mlx5: Refactor EEPROM query error handling to return status", " separately", " - octeontx2-pf: tc: fix egress ratelimiting", " - ice: allow creating VFs when !CONFIG_ICE_SWITCHDEV", " - drm: renesas: rzg2l_mipi_dsi: Increase reset deassertion delay", " - drm/displayid: move drm_displayid.h to drm_displayd_internal.h", " - drm/displayid: fix Tiled Display Topology ID size", " - drm/xe: Fix PTE index in xe_vm_populate_pgtable() for chunked binds", " - drm/amdkfd: Use kvcalloc to allocate arrays", " - drm/gfx10: Program DB_RING_CONTROL", " - drm/amdgpu: Disable PCIe dynamic speed switching on Ryzen Pinnacle Ridge", " - media: nuvoton: npcm-video: fix error handling in npcm_video_init()", " - media: qcom: camss: Fix RDI streaming for CSID GEN2", " - media: v4l2-subdev: Fail {enable,disable}_streams and s_streaming nicely", " - ALSA: timer: drain a slave's callback before its master detaches it", " - ALSA: timer: don't re-enter an instance callback that is still running", " - LoongArch: Retrieve CPU package ID from PPTT when available", " - sysctl: treewide: constify ctl_table_header::ctl_table_arg", " - ceph: fix refcount leak in ceph_readdir()", " - ASoC: fsl_sai: Fix spurious BCLK on resume by clearing BYP", " - net: move skb_gro_receive_list from udp to core", " - net: add pskb_may_pull() to skb_gro_receive_list()", " - vsock/virtio: collapse receive queue under memory pressure", " - drm/amd/pm: fix amdgpu_pm_info power display units", " - drm/amd/pm: fix smu13 power limit range calculation", " - drm/amd/display: Fix DTB DTO updates breaking live pixel rate sources", " - xfs: add an explicit owner field to xfs_da_args", " - xfs: factor out xfs_attr3_leaf_init", " - xfs: don't replace the wrong part of the cow fork", " - rxrpc: Fix CPU time starvation in I/O thread", " - ASoC: mediatek: mt8183-afe-pcm: Shorten memif_data table using macros", " - ASoC: mediatek: mt8183-afe-pcm: Support >32 bit DMA addresses", " - tcp: Decrement tcp_md5_needed static branch", " - nvmet: Introduce nvmet_req_transfer_len()", " - block: add helper add_disk_final()", " - block: remove redundant GD_NEED_PART_SCAN in add_disk_final()", " - Bluetooth: Add PA_LINK to distinguish BIG sync and PA sync connections", " - Bluetooth: hci_core: Fix not accounting for BIS/CIS/PA links separately", " - afs: Improve server refcount/active count tracing", " - afs: Make afs_lookup_cell() take a trace note", " - afs: Drop the net parameter from afs_unuse_cell()", " - rxrpc: Allow the app to store private data on peer structs", " - afs: Use the per-peer app data provided by rxrpc", " - afs: Fix afs_server ref accounting", " - afs: Simplify cell record handling", " - afs: Fix dynamic lookup to fail on cell lookup failure", " - afs: Fix lack of locking around modifications of net->cells_dyn_ino", " - lib/string_choices: Add str_plural() helper", " - USB: gadget: Use str_enable_disable-like helpers", " - usb: musb: omap2430: clean up probe error handling", " - net/mlx5e: Fix NULL pointer dereference in ioctl module EEPROM query", " - rxrpc: Fix locking issues with the peer record hash", " - wifi: nl80211: fix nl80211_start_radar_detection return value", " - afs: Set vllist to NULL if addr parsing fails", " - dpll: fix clock quality level reporting", " - afs: Fix delayed allocation of a cell's anonymous key", " - afs: handle CB.InitCallBackState3 requests without a server record", " - Bluetooth: hci_conn: Fix running bis_cleanup for hci_conn->type PA_LINK", " - Bluetooth: hci_conn: Fix not cleaning up Broadcaster/Broadcast Source", " - Bluetooth: hci_conn: Remove redundant memset after kzalloc", " - Bluetooth: hci_conn: Fix not cleaning up PA_LINK connections", " - Bluetooth: hci_conn: Fix memory leak in hci_le_big_terminate()", " - afs: Fix uninit var in afs_alloc_anon_key()", " - Upstream stable to v6.6.148, v6.12.101", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68371", " - usb: musb: omap2430: Do not put borrowed of_node in probe", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72130", " - nvmet-auth: reject short AUTH_RECEIVE buffers", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72168", " - mtd: maps: vmu-flash: fix fault in unaligned fixup", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72213", " - mm/hugetlb: fix hugetlb cgroup rsvd charge/uncharge mismatch", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72244", " - gpu/buddy: bail out of try_harder when alignment cannot be honoured", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68129", " - gve: fix Rx queue stall on alloc failure", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-53078", " - bpf: Fix same-register dst/src OOB read and pointer leak in sock_ops", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68119", " - tcp: initialize standalone TCP-AO response padding", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68136", " - net: gro: fix double aggregation of flush-marked skbs", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68139", " - net/mlx5e: Use sender devcom for MPV master-up", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68145", " - iomap: fix out-of-bounds bitmap_set() with zero-length range", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68161", " - sctp: close UDP tunnel sockets during netns teardown", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68162", " - sctp: avoid auth_enable sysctl UAF during netns teardown", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68178", " - misc: nsm: pin the module while the device is open", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68179", " - misc: nsm: only unlock nsm_dev on post-lock error paths", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68183", " - firmware: stratix10-svc: fix memory leaks and list corruption bugs", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68193", " - wifi: mt76: mt7925: drop TXRX_NOTIFY on non-mmio buses", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68203", " - media: vivid: fix cleanup bugs in vivid_init()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68205", " - media: v4l2-fwnode: Fix subdev owner overwritten in", " v4l2_async_register_subdev_sensor()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68221", " - media: nuvoton: npcm-video: fix memory leaks in probe and remove", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68225", " - media: i2c: alvium: fix critical pointer access in alvium_ctrl_init", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68228", " - media: chips-media: wave5: Move src_buf Removal to finish_encode", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68235", " - drm/amd/display: dce100: skip non-DP stream encoders for DP MST", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68247", " - drm/i915/bios: range check LFP Data Block panel_type2", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68260", " - drm/imagination: acquire vm_ctx->lock before mapping memory to GPU VM", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68261", " - drm/imagination: fix error checking of pvr_vm_context_lookup()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68262", " - drm/imagination: Fix user array stride in pvr_set_uobj_array()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68263", " - drm/imagination: Fix double call to drm_sched_entity_fini()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68437", " - drm/imagination: Fit paired fragment job in the correct CCCB", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68281", " - drm/imagination: Count paired job fence as dependency in prepare_job()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68290", " - rds: tcp: unregister sysctl before tearing down listen socket", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68293", " - net/mlx5: Fix MCIA register buffer overflow on 32 dword reads", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68439", " - wifi: mt76: mt7925: fix possible NULL-pointer deref in", " mt7925_mcu_bss_he_tlv()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68314", " - net: mctp i3c: clean up notifier and buses if driver register fails", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68318", " - pds_core: fix use-after-free on workqueue during remove", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68319", " - pds_core: fix deadlock between reset thread and remove", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68346", " - ALSA: hda: cs35l41: validate and free ACPI mute object", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2025-40098", " - ALSA: hda: cs35l41: Fix NULL pointer dereference in", " cs35l41_get_acpi_mute_state()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68442", " - btrfs: don't propagate EXTENT_FLAG_LOGGING to split extent maps", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68443", " - hwmon: (gigabyte_waterforce) Stop device IO before calling hid_hw_stop", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68372", " - usb: core: port: Deattach Type-C connector on component unbind", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68396", " - scsi: core: wake eh reliably when using scsi_schedule_eh", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68408", " - wifi: cfg80211: convert pmsr_free_wk to wiphy_work to fix deadlock", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64570", " - wifi: mac80211: fix fils_discovery double free on alloc failure", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64568", " - wifi: mac80211: fix unsol_bcast_probe_resp double free on alloc failure", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72175", " - fs/proc/task_mmu: fix make_uffd_wp_huge_pte() prot-update race", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-45901", " - netfilter: nf_tables: revert commit_mutex usage in reset path", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-45897", " - netfilter: nft_counter: serialize reset with spinlock", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68093", " - KVM: SVM: Bump asid_generation on CPU online to avoid ASID collision", " after hotplug", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68164", " - mm/damon/core: disallow overlapping input ranges for damon_set_regions()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68165", " - mm/damon/core: validate ranges in damon_set_regions()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72015", " - fs/resctrl: Fix double-add of pseudo-locked region's RMID to free list", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72017", " - net: macb: drop in-flight Tx SKBs on close", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72030", " - ata: libata-core: Reject an invalid concurrent positioning ranges count", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72023", " - octeontx2-pf: fix SQB pointer leak on init failure", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72040", " - ipmi: fix refcount leak in i_ipmi_request()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72045", " - octeontx2-af: cn10k: restrict VF LMTLINE sharing to its own PF", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72062", " - gpio: mt7621: avoid corruption of shared interrupt trigger state", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72051", " - net: ip6_tunnel: require CAP_NET_ADMIN in the device netns for", " changelink", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72065", " - net: mana: Validate the packet length reported by the NIC", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72069", " - locking/rt: Fix the incorrect RCU protection in rt_spin_unlock()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72070", " - wifi: libertas_tf: fix use-after-free in lbtf_free_adapter()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72142", " - i2c: imx: fix locked bus on SMBus block-read of 0 (atomic)", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72147", " - dmaengine: dw-edma-pcie: Reject devices without driver data", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72254", " - netfilter: nft_fib: reject fib expression on the netdev egress hook", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72253", " - netfilter: nf_conntrack_sip: validate skb_dst() before accessing it", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72260", " - ASoC: mediatek: mt8192: Check runtime resume during probe", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72305", " - VDUSE: avoid leaking information to userspace", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72299", " - tipc: restrict socket queue dumps in enqueue tracepoints", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-74436", " - rxrpc: serialize kernel accept preallocation with socket teardown", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64205", " - i2c: i801: fix hardware state machine corruption in error path", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68096", " - audit: fix recursive locking deadlock in audit_dupe_exe()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64280", " - fpga: dfl-afu: validate DMA mapping length in afu_dma_map_region()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68147", " - fscrypt: Avoid dynamic allocation in fscrypt_get_devices()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68123", " - openvswitch: fix GSO userspace truncation underflow", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68097", " - ksmbd: validate ACE size against SID sub-authorities", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68098", " - ksmbd: bound DACL dedup walk to copied ACEs", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68099", " - ksmbd: restore DACL size on check_add_overflow() to avoid malformed ACL", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68100", " - ksmbd: validate num_subauth when copying ACE in set_ntacl_dacl", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68104", " - drm/amdgpu: invoke pm_genpd_remove() before freeing genpd", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68106", " - drm/amdgpu: fix division by zero with invalid uvd dimensions", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68429", " - drm/dp_mst: Handle torn-down topology gracefully in", " drm_dp_mst_topology_queue_probe()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68107", " - drm/amdgpu/vcn4: avoid rereading IB param length", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68108", " - drm/amdgpu/vce: fix integer overflow in image size", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68110", " - drm/amdgpu/sdma4.4.2: replace BUG_ON() with WARN_ON()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68111", " - drm/amdgpu/gfx9: replace BUG_ON() with WARN_ON()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68112", " - drm/amdgpu/gfx9.4.3: replace BUG_ON() with WARN_ON()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68430", " - drm/amdgpu/gfx8: drop unecessary BUG_ON()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68246", " - drm/amdgpu/gfx11: replace BUG_ON() with WARN_ON()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68115", " - drm/amdgpu/gfx10: replace BUG_ON() with WARN_ON()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68116", " - vxlan: mdb: Fix source list corruption on a failed replace", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68117", " - tipc: clear sock->sk on the failed-insert path in tipc_sk_create()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68121", " - pppoe: reload header pointer after dev_hard_header()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68124", " - mctp: serial: handle zero-length frames to prevent rx buffer overflow", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68125", " - mac802154: llsec: reject frames shorter than the authentication tag", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68126", " - mac802154: hold an interface reference across the scan worker", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68127", " - ila: reload IPv6 header after pskb_may_pull in checksum adjust", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68130", " - ksmbd: defer destroy_previous_session() until after NTLM authentication", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68131", " - rbd: Reset positive result codes to zero in object map update path", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68135", " - net: hip04: fix RX buffer leak on build_skb failure", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68137", " - net/x25: fix use-after-free in x25_kill_by_neigh()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68140", " - net/iucv: fix use-after-free of a severed iucv_path", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68141", " - net/af_iucv: fix NULL deref in afiucv_hs_callback_syn()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68142", " - geneve: require CAP_NET_ADMIN in the device netns for changelink", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68143", " - net: slip: serialize receive against buffer reallocation", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68432", " - vxlan: require CAP_NET_ADMIN in the device netns for changelink", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68144", " - phonet: pep: fix use-after-free in pep_get_sb()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68146", " - ftrace: Add global mutex to serialize trace_parser access", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68148", " - fscrypt: Add missing superblock check in find_or_insert_direct_key()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68149", " - fs: preserve ACL_DONT_CACHE state in forget_cached_acl()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68151", " - binfmt_elf_fdpic: only honour the first PT_INTERP", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68153", " - libceph: remove debugfs files before client teardown", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68154", " - libceph: reject zero bucket types in crush_decode", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68155", " - libceph: Reject monmaps advertising zero monitors", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68156", " - libceph: refresh auth->authorizer_buf{,_len} after authorizer update", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68157", " - libceph: guard missing CRUSH type name lookup", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68158", " - libceph: Fix multiplication overflow in decode_new_up_state_weight()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68433", " - libceph: bound get_version reply decode to front len", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68160", " - ceph: fix pre-auth out-of-bounds read on snaptrace in ceph_handle_caps()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68175", " - tracing: Fix resource leak on mmiotrace trace_pipe close", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68176", " - tracing: Fix mmiotrace possible NULL dereferencing of hiter->dev", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68180", " - intel_th: fix MSC output device reference leak", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68181", " - mei: bus: access mei_device under device_lock on cleanup", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68182", " - comedi: comedi_parport: deal with premature interrupt", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68184", " - cdrom: fix stack out-of-bounds read in CDROMVOLCTRL", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68186", " - binfmt_misc: set have_execfd only once the interpreter is opened", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68187", " - exec: fix unsigned loop counter wrap in transfer_args_to_stack()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68188", " - Bluetooth: RFCOMM: Fix session UAF in set_termios", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68189", " - Bluetooth: hci_sync: Protect UUID list traversal", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68190", " - staging: rtl8723bs: fix OOB reads in rtw_get_wps_ie()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68192", " - wifi: brcmfmac: make release_scratchbuffers idempotent", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68194", " - wifi: mt76: mt7921: drop TXRX_NOTIFY on non-mmio buses", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68195", " - wifi: mt76: mt7615: drop TXRX_NOTIFY on non-mmio buses", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68196", " - wifi: wilc1000: validate assoc response length before subtracting header", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68197", " - wifi: mwifiex: fix NULL dereference when the AP has HT-cap but no HT-", " oper", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68199", " - wifi: ath6kl: fix OOB access from firmware ADDBA window size", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68202", " - ALSA: seq: close a re-opened queue timer in the destructor", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68204", " - media: vivid: check for vb2_is_busy() when toggling caps", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68206", " - media: v4l2-ctrls: validate HEVC active reference counts", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68207", " - media: ti: vpe: unwind v4l2 device registration on probe error", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68209", " - media: sun4i-csi: Return queued buffers on start_streaming() failure", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68210", " - media: stm32: dcmi: unregister notifier on probe failure", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68212", " - media: saa7134: Fix a possible memory leak in saa7134_video_init1", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68213", " - media: rtl2832_sdr: Return queued buffers on start_streaming() failure", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68214", " - media: rtl2832: fix use-after-free in rtl2832_remove()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68215", " - media: radio-si476x: Unregister v4l2_device on probe failure", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68216", " - media: pwc: Return queued buffers on start_streaming() failure", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68217", " - media: pwc: Drain fill_buf on start_streaming() failure", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68218", " - media: pci: dm1105: Free allocated workqueue", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68219", " - media: nxp: imx8-isi: Fix potential out-of-bounds issues", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68220", " - media: nxp: imx8-isi: Add missing v4l2_subdev_cleanup() in crossbar and", " pipe", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68222", " - media: msi2500: Return queued buffers on start_streaming() failure", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68223", " - media: meson: vdec: Fix memory leak in error path of vdec_open", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68226", " - media: cx23885: add ioremap return check and cleanup", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68227", " - media: cx231xx: fix devres lifetime", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68229", " - media: cedrus: skip invalid H.264 reference list entries", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68231", " - media: airspy: Return queued buffers on start_streaming() failure", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68445", " - drm/vc4: Prevent shader BO mappings from becoming writable", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68446", " - drm/vmwgfx: Validate vmw_surface_metadata::array_size", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68234", " - drm/amdgpu: fix bo->pin leaking in amdgpu_bo_create_reserved", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68236", " - drm/amd/display: set new_stream to NULL after release", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68243", " - drm/i915/gem: Fix NULL deref in I915_CONTEXT_PARAM_SSEU", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68244", " - drm/i915/gem: Do not leak siblings[] on proto context error", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68248", " - drm/i915: Return NULL on error in active_instance", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68249", " - drm/amdgpu/sdma5.0: replace BUG_ON() with WARN_ON()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68250", " - drm/amdgpu/sdma5.2: replace BUG_ON() with WARN_ON()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68251", " - drm/amdgpu/sdma6.0: replace BUG_ON() with WARN_ON()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68255", " - drm/virtio: bound EDID block reads to the response buffer", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68256", " - drm/amd/display: detect_link_and_local_sink: DP alt mode timeout path", " leaks prev_sink reference", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68259", " - drm/amdkfd: Check bounds in allocate_event_notification_slot", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68269", " - drm/i915/gem: Add missing nospec on parallel submit slot", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68271", " - drm/nouveau: fix reversed error cleanup order in ucopy functions", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68272", " - drm/amdgpu: validate CP_GFX_SHADOW chunk size in CS pass1", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68277", " - drm/dp/mst: fix OOB reads on 2-byte fields in sideband reply parsers", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68278", " - drm/dp/mst: fix buffer overflows in sideband chunk accumulation", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68279", " - drm/dp/mst: fix OOB reads in remote DPCD/I2C sideband reply parsers", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68280", " - drm/bridge: cdns-dsi: Replace deprecated UNIVERSAL_DEV_PM_OPS()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68284", " - bpf, sockmap: Fix cork use-after-free in tcp_bpf_sendmsg()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68294", " - net: qrtr: restrict socket creation to the initial network namespace", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68297", " - tipc: fix u16 MTU truncation in media and bearer MTU validation", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68299", " - vmxnet3: fix BUG_ON in vmxnet3_get_hdr_len() for Geneve packets", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68300", " - sctp: auth: verify auth requirement when auth_chunk is NULL", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68301", " - net: hsr: fix memory leak on slave unregistration by removing synced", " VLANs", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68302", " - amt: re-read skb header pointers after every pull", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68304", " - wifi: brcmfmac: fix 802.1X-SHA256 call trace warning", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68306", " - wifi: mt76: mt7996: fix possible NULL-pointer deref in", " mt7996_mcu_sta_bfer_eht()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68308", " - wifi: mt76: mt7996: check pointer returned by", " mt76_connac_get_he_phy_cap()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68309", " - wifi: mt76: connac: fix possible NULL-pointer deref in", " mt76_connac_mcu_uni_bss_he_tlv()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68310", " - wifi: mt76: mt7915: guard HE capability lookups", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68313", " - tipc: fix infinite loop in __tipc_nl_compat_dumpit", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64576", " - nexthop: initialize extack in nh_res_bucket_migrate()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64577", " - gtp: check skb_pull_data() return in gtp1u_send_echo_resp()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68315", " - sctp: validate stream count in sctp_process_strreset_inreq()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68317", " - pds_core: fix auxiliary device add/del races", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68320", " - sctp: fix auth_chunk_list capacity check in sctp_auth_ep_add_chunkid", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68324", " - iommu/intel: Fix out-of-bounds memset in dmar_latency_disable()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68325", " - iommu/amd: Bound the early ACPI HID map", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68326", " - wifi: mwifiex: bound uAP association event IEs to the event buffer", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68327", " - wan: wanxl: Only reset hardware after BAR mapping", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68328", " - nfp: Check resource mutex allocation", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64574", " - wifi: mac80211: tear down new links on vif update error path", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68329", " - iommu/amd: Wait for completion instead of returning early in", " iommu_completion_wait()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68331", " - dpaa2-eth: put MAC endpoint device on disconnect", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68333", " - dpaa2-switch: put MAC endpoint device on disconnect", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68335", " - rds: drop incoming messages that cross network namespace boundaries", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68336", " - bonding: fix devconf_all NULL dereference when IPv6 is disabled", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68338", " - net/packet: avoid fanout hook re-registration after unregister", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68339", " - Bluetooth: btusb: validate Realtek vendor event length", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68340", " - hwmon: occ: validate poll response sensor blocks", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68343", " - smb: client: validate DFS referral PathConsumed", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68348", " - ASoC: tas2781: bound firmware description string parsing", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68450", " - btrfs: free mapping node on duplicate reloc root insert", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68349", " - wifi: carl9170: fix buffer overflow in rx_stream failover path", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68350", " - wifi: carl9170: fix OOB read from off-by-two in TX status handler", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68351", " - wifi: carl9170: bound memcpy length in cmd callback to prevent OOB read", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68352", " - wifi: ath6kl: fix OOB read from firmware IE lengths in connect event", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68353", " - wifi: ath6kl: fix OOB read from firmware num_msg in TX complete handler", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68354", " - firewire: net: Fix fragmented datagram reassembly", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68355", " - wifi: ath11k: fix potential buffer underflow in", " ath11k_hal_rx_msdu_list_get()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68357", " - watchdog: pretimeout: Fix UAF in watchdog_unregister_governor()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68359", " - hwmon: (nzxt-smart2) Stop device IO before calling hid_hw_stop", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68360", " - hwmon: (corsair-cpro) Stop device IO before calling hid_hw_stop", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68361", " - hwmon: (corsair-psu) Stop device IO before calling hid_hw_stop", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68362", " - wifi: ath11k: fix NULL pointer dereference in", " ath11k_hal_srng_access_begin", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68363", " - wifi: ath9k: hif_usb: don't dereference hif_dev after re-arming firmware", " request", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68365", " - USB: serial: io_edgeport: cap received transmit credits", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68366", " - usb: gadget: uvc: clamp SEND_RESPONSE length to the response buffer", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64583", " - usb: gadget: udc: bdc: free IRQ and drain func_wake_notify before", " teardown", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68368", " - usb: gadget: f_ncm: validate datagram bounds in ncm_unwrap_ntb()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68369", " - usb: gadget: printer: fix infinite loop in printer_read()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64584", " - usb: gadget: f_midi: cancel pending IN work before freeing the midi", " object", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68370", " - usb: gadget: dummy_hcd: prevent fifo_req reuse during giveback", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68373", " - wifi: at76c50x-usb: avoid length underflow in at76_guess_freq()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64569", " - mpls: fix NULL deref in mpls_valid_fib_dump_req() on CONFIG_INET=n", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68376", " - sctp: fix auth_hmacs array size in struct sctp_cookie", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68377", " - net/sched: act_tunnel_key: Defer dst_release to RCU callback", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64578", " - ksmbd: validate compound request size before reading StructureSize2", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68381", " - ksmbd: pin conn during async oplock break notification", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68386", " - bpf, sockmap: Reject unhashed UDP sockets on sockmap update", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68388", " - smb/client: handle overlapping allocated ranges in fallocate", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68389", " - Bluetooth: hci_qca: Clear memdump state on invalid dump size", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68391", " - Bluetooth: mgmt: hold reference for hci_conn in mgmt_pending_cmds", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68392", " - Bluetooth: mgmt: fix locking in unpair_device/disconnect_sync", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64573", " - Bluetooth: qca: fix NVM tag length underflow in TLV parser", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68449", " - ata: sata_dwc_460ex: fix infinite loop in NCQ tag completion bit-", " scanning", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68395", " - ata: sata_dwc_460ex: enable SATA interrupts only after IRQ handler is", " registered", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68397", " - net/iucv: take a reference on the socket found in afiucv_hs_rcv()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64572", " - ipv4: fib: free fib_alias with kfree_rcu() on insert error path", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68398", " - ppp: defer channel free to an RCU grace period to fix pppol2tp RX UAF", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68402", " - wifi: cfg80211: bound element ID read when checking non-inheritance", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68403", " - wifi: brcmfmac: initialize SDIO data work before cleanup", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68405", " - wifi: mac80211: free AP_VLAN bc_buf SKBs outside IRQ lock", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68406", " - wifi: cfg80211: validate PMSR FTM preamble range", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68407", " - wifi: nl80211: free RNR data on MBSSID mismatch", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64571", " - wifi: p54: validate RX frame length in p54_rx_eeprom_readback()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68410", " - wifi: libertas: fix memory leak in helper_firmware_cb()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68411", " - wifi: mac80211_hwsim: clamp virtio RX length before skb_put", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68413", " - wifi: ipw2100: fix potential memory leak in ipw2100_pci_init_one()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68414", " - wifi: cfg80211: cancel sched scan results work on unregister", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64579", " - xfrm: policy: preallocate inexact bins before xfrm_hash_rebuild reinsert", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64580", " - xfrm6: clear dst.dev on error to avoid double netdev_put in", " xfrm6_fill_dst()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68416", " - mtd: fix double free and WARN_ON in add_mtd_device() error paths", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68417", " - RDMA/siw: publish QP after initialization", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68419", " - RDMA/irdma: Prevent rereg_mr for non-mem regions", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68444", " - firmware: arm_ffa: Fix NULL dereference in ffa_partition_info_get()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68422", " - btrfs: fix root leak if its reloc root is unexpected in", " merge_reloc_roots()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64567", " - btrfs: reject free space cache with more entries than pages", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68425", " - IB/mad: Drop unmatched RMPP responses before reassembly", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64565", " - Input: ims-pcu - fix heap-buffer-overflow in ims_pcu_process_data()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68427", " - gpu: host1x: Fix use-after-free in host1x_bo_clear_cached_mappings", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72146", " - dmaengine: sh: rz-dmac: Move interrupt request after everything is set", " up", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72124", " - can: isotp: serialize TX state transitions under so->rx_lock", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72125", " - can: isotp: fix use-after-free race with concurrent NETDEV_UNREGISTER", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72115", " - can: bcm: track a single source interface for ANYDEV timeout/throttle", " ops", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72117", " - can: bcm: fix data race on rx_stamp/rx_ifindex in bcm_rx_handler()", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72116", " - can: bcm: fix stale rx/tx ops after device removal", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72113", " - can: bcm: add missing device refcount for CAN filter removal", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72114", " - can: bcm: validate frame length in bcm_rx_setup() for RTR replies", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72119", " - can: bcm: extend bcm_tx_lock usage for data and timer updates", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72118", " - can: bcm: fix CAN frame rx/tx statistics", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-72121", " - can: bcm: add locking when updating filter and timer values", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-68428", " - KVM: x86/mmu: Fix use-after-free on vendor module reload", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64562", " - KVM: nVMX: Hide shadow VMCS right after VMCLEAR", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-64561", " - KVM: x86: Check for invalid/obsolete root *after* making MMU pages", " available", "", " * Noble update: upstream stable patchset 2026-09-23 (LP: #2168026) //", " CVE-2026-53090", " - bpf: Fix ld_{abs,ind} failure path analysis in subprogs", "", " * test_vxlan_vnifiltering.sh from ubuntu_kselftests_net failed on linux-", " oem-6.8 (with ipv6 default rdst) (LP: #2071590)", " - selftests: net: use slowwait to make sure IPv6 setup finished", "", " * ubuntu_bpf failed to build in noble (error: redefinition of", " 'stack_load_preserves_const_precision') (LP: #2160493)", " - SAUCE: Revert \"selftests/bpf: validate fake register spill/fill", " precision backtracking logic\"", "", " * CVE-2026-64564", " - sctp: don't free the ASCONF's own transport in DEL-IP processing", "", " * Backport: \"mm/gup: fix GUP-fast fallback for NULL-mapping order-0 folios\"", " (LP: #2162917)", " - mm/gup: fix GUP-fast fallback for NULL-mapping order-0 folios", "", " * qrtr: ns: node limit of 64 breaks QRTR routing on large multi-node", " deployments (LP: #2165140)", " - net: qrtr: ns: Raise node count limit to 512", "", " * [UBUNTU 24.04] kernel: CPU hotplug unsupported by CPUMF (LP: #2165732)", " - s390/cpum_cf: Handle CPU hotplug via prepare/dead callbacks", "", " * CVE-2026-68399", " - bpf: Fix UAF in sock clone early bailouts", "", " * CVE-2025-38563", " - perf/core: Prevent VMA split of buffer mappings", "", " * CVE-2025-38565", " - perf/core: Exit early on perf_mmap() fail", "", " * CVE-2025-38187", " - drm/nouveau: fix a use-after-free in r535_gsp_rpc_push()", "", " * CVE-2025-38069", " - PCI: endpoint: pci-epf-test: Fix double free that causes kernel to oops", "", " * CVE-2025-40014", " - objtool, spi: amd: Fix out-of-bounds stack access in amd_set_spi_freq()", "", " * CVE-2025-21985", " - drm/amd/display: Fix out-of-bound accesses", "", " * CVE-2024-56552", " - drm/xe/guc_submit: fix race around suspend_pending", "", " * CVE-2025-21687", " - vfio/platform: check the bounds of read/write syscalls", "", " * Noble update: upstream stable patchset 2026-09-14 (LP: #2167237)", " - ext4: fix fd leak in EXT4_IOC_MOVE_EXT cross-sb validation", " - mm: refactor mm_access() to not return NULL", " - Upstream stable to v6.6.146, v6.12.98, v6.6.147, v6.12.99, v6.12.100", "", " * Noble update: upstream stable patchset 2026-09-14 (LP: #2167237) //", " CVE-2026-64560", " - posix-cpu-timers: Prevent UAF caused by non-leader exec() race", "", " * Noble update: upstream stable patchset 2026-09-10 (LP: #2166995)", " - bpf, arm64: Reject out-of-range B.cond targets", " - nfsd: release layout stid on setlease failure", " - Bluetooth: btmtk: apply the common btmtk_fw_get_filename", " - Bluetooth: btmtk: Fix failed to send func ctrl for MediaTek devices.", " - Bluetooth: btmtk: Fix wait_on_bit_timeout interruption during shutdown", " - userfaultfd: gate must_wait writability check on pte_present()", " - perf: Fix dangling cgroup pointer in cpuctx backport", " - Bluetooth: btmtk: Fix btmtk.c undefined reference build error", " - device property: initialize the remaining fields of fwnode_handle in", " fwnode_init()", " - f2fs: validate orphan inode entry count", " - f2fs: atomic: fix UAF issue on f2fs_inode_info.atomic_inode", " - f2fs: fix potential deadlock in f2fs_balance_fs()", " - f2fs: fix potential deadlock in gc_merge path of f2fs_balance_fs()", " - f2fs: fix listxattr handling of corrupted xattr entries", " - block: Avoid mounting the bdev pseudo-filesystem in userspace", " - i2c: core: fix irq domain leak on adapter registration failure", " - i2c: core: fix hang on adapter registration failure", " - i2c: core: fix NULL-deref on adapter registration failure", " - i2c: core: fix adapter debugfs creation", " - fbdev: fbcon: fix out-of-bounds read in err_out of fbcon_do_set_font()", " - NFSv4/flexfiles: reject zero filehandle version count", " - locking/rtmutex: Make sure we wake anything on the wake_q when we", " release the lock->wait_lock", " - bonding: fix xfrm offload feature setup on active-backup mode", " - mm/vmscan: flush deferred TLB before freeing large folios", " - perf trace beauty fcntl: Fix build with older kernel headers", " - ACPI: CPPC: Suppress UBSAN warning caused by field misuse", " - ACPI: NFIT: core: Fix possible NULL pointer dereference", " - perf/core: Detach event groups during remove_on_exec", " - arm64: sysreg: Add layout for ID_AA64MMFR4_EL1", " - virtio_net: Support dynamic rss indirection table size", " - LoongArch: Add PIO for early access before ACPI PCI root register", " - usb: gadget: function: rndis: add length check to response query", " - usb: gadget: function: rndis: add length check for header", " - iio: accel: bmc150: clamp the device-reported FIFO frame count", " - iio: accel: kxsd9: fix runtime PM imbalance on write_raw() error", " - iio: adc: lpc32xx: Initialize completion before requesting IRQ", " - iio: adc: ti-ads124s08: Return reset GPIO lookup errors", " - iio: chemical: scd30: Cleanup initializations and fix sign-extension bug", " - iio: event: Fix event FIFO reset race", " - iio: gyro: bmg160: bail out when bandwidth/filter is not in table", " - iio: gyro: bmg160: wait full startup time after mode change at probe", " - iio: imu: bmi160: add IRQF_NO_THREAD to data-ready trigger IRQ", " - iio: imu: st_lsm6dsx: deselect shub page before reading whoami", " - iio: light: al3010: fix incorrect scale for the highest gain range", " - iio: light: gp2ap002: fix runtime PM leak on read error", " - iio: light: opt3001: fix missing state reset on timeout", " - iio: light: tsl2591: return actual error from probe IRQ failure", " - iio: light: veml6030: fix channel type when pushing events", " - iio: magnetometer: ak8975: Add missed pm_runtime_put_autosuspend() call", " - iio: temperature: ltc2983: Fix reinit_completion() called after", " conversion start", " - ALSA: virtio: Add missing 384 kHz PCM rate mapping", " - ALSA: ymfpci: check snd_ctl_new1() return value", " - ALSA: caiaq: fix out-of-bounds read in the Traktor Kontrol S4 input", " parser", " - ALSA: cmipci: check snd_ctl_new1() return value", " - ALSA: es1938: check snd_ctl_new1() return value", " - ALSA: firewire: isight: bound the sample count to the packet payload", " - ALSA: gus: check snd_ctl_new1() return value", " - ALSA: ice1712: check snd_ctl_new1() return value", " - ALSA: seq: Fix uninitialised heap leak in snd_seq_event_dup()", " - ALSA: usb-audio: avoid kobject path lookup in DualSense match", " - ALSA: usb-audio: Propagate errors in scarlett_ctl_enum_put()", " - ALSA: usb-audio: Propagate US-16x08 write errors in route/mix EQ-switch", " put callbacks", " - ALSA: usb-audio: Update Babyface Pro control caches only after", " successful writes", " - ALSA: usb-audio: Update US-16x08 EQ/comp shadow state after successful", " writes", " - vfio/pci: Use a private flag to prevent power state change with VFs", " - vfio/pci: Latch disable_idle_d3 per device", " - vfio/pci: Release the VGA arbiter client on register_device() failure", " - vfio/pci: Fix racy bitfields and tighten struct layout", " - vfio: prevent infinite loop in vfio_mig_get_next_state() on blocked arc", " - Bluetooth: btusb: Add USB ID 2c4e:0128 for Mercusys MA60XNB", " - Bluetooth: btusb: fix use-after-free on registration failure", " - Bluetooth: btusb: fix use-after-free on marvell probe failure", " - Bluetooth: btusb: fix wakeup source leak on probe failure", " - binder: fix UAF in binder_thread_release()", " - binder: fix UAF in binder_free_transaction()", " - usb: xhci: Fix sleep in atomic context in xhci_free_streams()", " - PCI: altera: Do not dispose parent IRQ mapping", " - mm/damon/ops-common: handle extreme intervals in damon_hot_score()", " - netfilter: ipset: fix race between dump and ip_set_list resize", " - virtio-mmio: fix device release warning on module unload", " - hwrng: virtio: clamp device-reported used.len at copy_data()", " - USB: chaoskey: Fix slab-use-after-free in chaoskey_release()", " - usb: dwc3: run gadget disconnect from sleepable suspend context", " - 6lowpan: fix NHC entry use-after-free on error path", " - tipc: fix out-of-bounds read in broadcast Gap ACK blocks", " - staging: vme_user: bound slave read/write to the kern_buf size", " - smb: client: restrict implied bcc[0] exemption to responses without data", " area", " - staging: vme_user: fix location monitor leak in fake bridge", " - staging: vme_user: fix location monitor leak in tsi148 bridge", " - media: staging: ipu3-imgu: Add range check for imgu_css_cfg_acc_stripe", " - staging: media: atomisp: reduce load_primary_binaries() stack usage", " - staging: rtl8723bs: fix heap buffer overflow in", " rtw_cfg80211_set_wpa_ie()", " - staging: rtl8723bs: fix WEP length underflow and OOB read in OnAuth()", " - staging: rtl8723bs: fix OOB read in OnAssocRsp() IE loop", " - staging: rtl8723bs: fix OOB read in update_beacon_info() IE loop", " - staging: rtl8723bs: fix OOB reads in IE loops in issue_assocreq() and", " join_cmd_hdl()", " - staging: rtl8723bs: fix OOB reads in is_ap_in_tkip() IE loop", " - staging: rtl8723bs: fix OOB write in HT_caps_handler()", " - crypto: amlogic - avoid double cleanup in meson_crypto_probe()", " - ksmbd: fix use-after-free of a deferred file_lock on SMB2_CLOSE then", " SMB2_CANCEL", " - net: af_key: initialize alg_key_len for IPComp states", " - audit: Fix data races of skb_queue_len() readers on audit_queue", " - Bluetooth: MGMT: Fix UAF of hci_conn_params in add_device_complete", " - debugobjects: Plug race against a concurrent OOM disable", " - fs/ntfs3: validate Dirty Page Table capacity in log_replay copy_lcns", " - NTB: epf: Avoid calling pci_irq_vector() from hardirq context", " - io_uring/io-wq: re-check IO_WQ_BIT_EXIT for each linked work item", " - ipv4: igmp: remove multicast group from hash table on device destruction", " - net: ipv4: bound TCP reordering sysctl writes and MTU probe sizes", " - mfd: cros_ec: Delay dev_set_drvdata() until probe success", " - mm: shrinker: fix NULL pointer dereference in debugfs", " - netfilter: ctnetlink: use nf_ct_exp_net() in expectation dump", " - f2fs: bound i_inline_xattr_size for non-inline-xattr inodes", " - drm/amd: Fix set but not used warnings", " - apparmor: advertise the tcp fast open fix is applied", " - nfsd: move name lookup out of nfsd4_list_rec_dir()", " - nfsd: change nfs4_client_to_reclaim() to allocate data", " - arm64: Treat HCR_EL2.E2H as RES1 when ID_AA64MMFR4_EL1.E2H0 is negative", " - arm64: Fix early handling of FEAT_E2H0 not being implemented", " - KVM: arm64: Initialize HCR_EL2.E2H early", " - arm64: Revamp HCR_EL2.E2H RES1 detection", " - arm64: sysreg: Correct sign definitions for EIESB and DoubleLock", " - iio: adc: spear: Initialize completion before requesting IRQ", " - iio: imu: inv_icm42600: fix timestamp clock period by using lower value", " - ALSA: usb-audio: Roll back quirk control caches on write errors", " - usb: typec: tcpci_rt1711h: unregister TCPCI port with devres", " - gpio: eic-sprd: use raw_spinlock_t in the irq startup path", " - netfilter: ebtables: module names must be null-terminated", " - netfilter: ebtables: terminate table name before find_table_lock()", " - Bluetooth: btmtksdio: fix infinite loop in btmtksdio_txrx_work()", " - Bluetooth: bnep: pin L2CAP connection during netdev registration", " - Bluetooth: btnxpuart: Fix out-of-bounds firmware read in", " nxp_recv_fw_req_v3()", " - Bluetooth: fix UAF in bt_accept_dequeue()", " - Bluetooth: L2CAP: validate option length before reading conf opt value", " - fs/ntfs3: fsync files by syncing parent inodes", " - fs/ntfs3: zero-fill folios beyond i_valid in ntfs_read_folio()", " - fs/ntfs3: fix missing run load for vcn0 in attr_data_get_block_locked()", " - coresight: ultrasoc-smb: Fix OOB write in smb_sync_perf_buffer()", " - smb/client: Fix error code in smb2_aead_req_alloc()", " - ksmbd: add permission checks for FSCTL_DUPLICATE_EXTENTS_TO_FILE", " - ksmbd: add a permission check for FSCTL_SET_ZERO_DATA", " - ksmbd: serialize QUERY_DIRECTORY requests per file", " - ksmbd: require source read access for duplicate extents", " - ksmbd: fix UAF of struct file_lock in SMB2_LOCK deferred-lock", " cancellation", " - ksmbd: add a WRITE_DAC/WRITE_OWNER check to SMB2 SET_INFO SECURITY", " - ksmbd: run set info with opener credentials", " - ksmbd: enforce FILE_READ_ATTRIBUTES on SMB_FIND_FILE_POSIX_INFORMATION", " - ksmbd: add per-handle permission check to FILE_LINK_INFORMATION", " - ksmbd: use opener credentials for delete-on-close", " - smb: client: fix query directory replay double-free", " - smb: client: fix query_info() replay double-free", " - smb: client: fix double-free in SMB2_ioctl() replay", " - smb: client: fix change notify replay double-free", " - smb: client: fix double-free in SMB2_flush() replay", " - smb: client: fix double-free in SMB2_open() replay", " - smb: client: fix double-free in SMB2_close() replay", " - smb: client: Fix next buffer leak in receive_encrypted_standard()", " - smb: client: use unaligned reads in parse_posix_ctxt()", " - smb: client: harden POSIX SID length parsing", " - smb: client: mask server-provided mode to 07777 in modefromsid", " - OPP: of: Fix potential memory leak in opp_parse_supplies()", " - firmware_loader: fix device reference leak in firmware_upload_register()", " - cpufreq: intel_pstate: Sync policy->cur during CPU offline", " - sched/rt: Have RT_PUSH_IPI be default off for non PREEMPT_RT", " - cpufreq: Fix hotplug-suspend race during reboot", " - cpufreq: pcc: fix use-after-free and double free in _OSC evaluation", " - posix-cpu-timers: Fix pid refcount leak in do_cpu_nanosleep() error path", " - clocksource/drivers/timer-tegra186: Fix support for multiple watchdog", " instances", " - X.509: Fix validation of ASN.1 certificate header", " - tools/mm/slabinfo: Fix trace disable logic inversion", " - tools/mm/slabinfo: fix total_objects attribute name", " - HID: wacom: stop hardware after post-start probe failures", " - HID: letsketch: fix UAF on inrange_timer at driver unbind", " - HID: lg-g15: cancel pending work on remove to fix a use-after-free", " - HID: sensor-hub: Add sensor_hub_input_attr_read_values() for multi-byte", " reads", " - hfs/hfsplus: zero-initialize buffer in hfs_bnode_read", " - nilfs2: reject CLEAN_SEGMENTS ioctl with out-of-range segment numbers", " - media: mtk-jpeg: cancel workqueue on release for supported platforms", " only", " - xfs: use null daddr for unset first bad log block", " - xfs: fix unreachable BIGTIME check in dquot flush validation", " - bpf: Reject fragmented frames in devmap", " - bpf: Restore sysctl new-value from 1 to 0", " - net: usb: kalmia: bound RX frame length in kalmia_rx_fixup()", " - usb: cdc_acm: Add quirk for Uniden BC125AT scanner", " - usb: cdnsp: fix stream context array leak in cdnsp_alloc_stream_info()", " - USB: core: add USB_QUIRK_NO_LPM for VIA Labs USB 2.0 hub", " - usb: dwc3: meson-g12a: fix refcount leak in dwc3_meson_g12a_resume()", " - usb: free iso schedules on failed submit", " - usb: gadget: composite: fix dead empty check in the USB_DT_OTG handler", " - usb: gadget: udc: Fix use-after-free in gadget_match_driver", " - usb: gadget: f_printer: take kref only for successful open", " - USB: idmouse: fix use-after-free on disconnect race", " - USB: ldusb: fix use-after-free on disconnect race", " - USB: iowarrior: fix use-after-free on disconnect", " - USB: quirks: add NO_LPM for the Samsung T5 EVO Portable SSD", " - USB: legousbtower: fix use-after-free on disconnect race", " - usb: sl811-hcd: disable controller wakeup on remove", " - USB: storage: include US_FL_NO_SAME in quirks mask", " - USB: misc: uss720: unregister parport on probe failure", " - usb: mtu3: unmap request DMA on queue failure", " - USB: serial: keyspan_pda: fix information leak", " - USB: serial: option: add Telit Cinterion FE990D50 compositions", " - USB: serial: digi_acceleport: fix broken rx after throttle", " - USB: serial: digi_acceleport: fix hard lockup on disconnect", " - USB: serial: digi_acceleport: fix write buffer corruption", " - USB: ulpi: fix memory leak on registration failure", " - USB: usb-storage: ene_ub6250: restore media-ready check", " - usbip: tools: support SuperSpeedPlus devices", " - usbip: vudc: fix NULL deref in vep_dequeue()", " - usb: typec: anx7411: use devm_pm_runtime_enable()", " - usb: typec: class: drop PD lookup reference", " - usb: typec: tcpm: Validate SVID index in svdm_consume_modes()", " - usb: typec: ucsi: Invert DisplayPort role assignment", " - usb: typec: ucsi: Pass full DP config payload in SET_NEW_CAM for DP alt", " mode", " - usb: typec: ucsi: ccg: Fix use-after-free of ucsi on remove", " - usb: typec: ucsi: cancel pending work on system suspend", " - iio: temperature: ltc2983: Fix n_wires default bypassing rotation check", " - PCI: Always lift 2.5GT/s restriction in PCIe failed link retraining", " - udf: validate free block extents against the partition length", " - udf: validate VAT header length against the VAT inode size", " - udf: validate sparing table length as an entry count, not a byte count", " - hwrng: jh7110 - fix refcount leak in starfive_trng_read()", " - dm-ioctl: report an error if a device has no table", " - nvme-multipath: set BIO_REMAPPED on bios remapped to per-path namespace", " disks", " - btrfs: do not trim a device which is not writeable", " - partitions: aix: bound the pp_count scan to the ppe array", " - isofs: bound Rock Ridge symlink components to the SL record", " - crypto: af_alg - Remove zero-copy support from skcipher and aead", " - crypto: caam - use print_hex_dump_devel to guard key hex dumps", " - crypto: caam - use print_hex_dump_devel to guard key hex dumps again", " - crypto: ecc - Fix carry overflow in vli multiplication", " - crypto: pcrypt - restore callback for non-parallel fallback", " - crypto: drbg - Fix returning success on failure in CTR_DRBG", " - crypto: drbg - Fix drbg_max_addtl() on 64-bit kernels", " - crypto: drbg - Fix the fips_enabled priority boost", " - crypto: qat - validate RSA CRT component lengths", " - crypto: talitos - use dma_sync_single_for_cpu() before reading", " descriptor header", " - crypto: talitos - add chaining of arbitrary number of descriptor for the", " SEC1", " - crypto: talitos - move dma unmapping code in flush_channel() into a", " standalone dma_unmap_request() function", " - crypto: talitos - move dma mapping code in talitos_submit() into a", " standalone dma_map_request() function", " - crypto: talitos - move code in current_desc_hdr() into a standalone", " function", " - crypto: talitos/hash - prepare SEC1 descriptor chaining, remove", " additional descriptor", " - crypto: talitos/hash - use descriptor chaining for SEC1 instead of", " workqueue", " - crypto: talitos/hash - drop workqueue mechanism for SEC1", " - crypto: talitos/hash - rename first_desc/last_desc to", " first_request/last_request", " - crypto: talitos/hash - remove useless wrapper", " - crypto: talitos/hash - fix SEC2 64k - 1 ahash request limitation", " - arm64: fpsimd: Fix type mismatch in sme_{save,load}_state()", " - spi: fsl-lpspi: replace dmaengine_terminate_all() with", " dmaengine_terminate_sync()", " - spi: fsl-lpspi: terminate the RX channel on TX prepare failure path", " - EDAC/i10nm: Don't fail probing if ADXL is missing", " - watchdog: apple: Add \"apple,t8103-wdt\" compatible", " - tracing: Prevent out-of-bounds read in glob matching", " - NFSv4: include MAY_WRITE in open permission mask for O_TRUNC", " - module: decompress: check return value of module_extend_max_pages()", " - exfat: bound uniname advance in exfat_find_dir_entry()", " - NTB: epf: Fix request_irq() unwind in ntb_epf_init_isr()", " - KVM: VMX: Refresh GUEST_PENDING_DBG_EXCEPTIONS.BS on all injected #DBs", " - KVM: VMX: Grab vmcs12 on CR8 interception update iff vCPU is in guest", " mode", " - udmabuf: fix DMA direction mismatch in release_udmabuf()", " - i2c: core: fix adapter deregistration race", " - i2c: mpc: Fix timeout calculations", " - i2c: stm32f7: truncate clock period instead of rounding it", " - Input: synaptics-rmi4 - unregister function handlers on physical driver", " registration failure", " - Input: synaptics-rmi4 - bound the F3A keymap to the GPIO count", " - Input: synaptics-rmi4 - bound the F30 keymap to the GPIO/LED count", " - Input: elan_i2c - prevent division by zero and arithmetic underflow", " - Input: goodix - clamp the device-reported contact count", " - Input: iforce - bound the device-reported force-feedback effect index", " - Input: mms114 - fix touch indexing for MMS134S and MMS136", " - Input: touchwin - reset the packet index on every complete packet", " - Input: mms114 - reject an oversized device packet size", " - Input: maplemouse - fix NULL pointer dereference in open()", " - Input: mms114 - fix multi-touch slot corruption", " - Input: maple_keyb - set driver data before registering input device", " - Input: maplemouse - set driver data before registering input device", " - Input: maplecontrol - set driver data before registering input device", " - RDMA/rtrs-srv: Bound RDMA-Write length to chunk size in rdma_write_sg", " - fuse: fix device node leak in cuse_process_init_reply()", " - fuse: re-lock request before returning from fuse_ref_folio()", " - smb: client: reject overlapping data areas in SMB2 responses", " - xfs: fail recovery on a committed log item with no regions", " - xfs: resample the data fork mapping after cycling ILOCK", " - smb/server: do not require delete access for non-replacing links", " - sched/fair: Only update stats for allowed CPUs when looking for dst", " group", " - KVM: arm64: Bound used_lrs when flushing the pKVM hyp vCPU", " - KVM: arm64: Clear __hyp_running_vcpu when flushing the pKVM hyp vCPU", " - nvmet-tcp: check INIT_FAILED before nvmet_req_uninit in digest error", " path", " - nvmet-tcp: Fix potential UAF when ddgst mismatch", " - crypto: sun4i-ss - Remove insecure and unused rng_alg", " - [Config] Remove CRYPTO_DEV_SUN4I_SS_PRNG", " - crypto: crypto4xx - Remove ahash-related code", " - bpf: Support for hardening against JIT spraying", " - x86/bugs: Enable IBPB flush on BPF JIT allocation", " - media: uvcvideo: Avoid partial metadata buffers", " - media: uvcvideo: Fix buffer sequence in frame gaps", " - media: uvcvideo: Fix sequence number when no EOF", " - dt-bindings: media: sun4i-a10-video-engine: Add interconnect properties", " - dt-bindings: power: imx93: Add MIPI PHY power domain", " - serial: msm: Disable DMA for kernel console UART", " - serial: 8250_omap: clear rx_running on zero-length DMA completes", " - rxrpc: rxrpc_verify_data ensure rx_dec_buffer alloc", " - rxrpc: Fix leak of released call in recvmsg(MSG_PEEK)", " - afs: Fix netns teardown to cancel the preallocation charger", " - afs: fix NULL pointer dereference in afs_get_tree()", " - afs: Fix further netns teardown to cancel the preallocation charger", " - fbcon: fix NULL pointer dereference for a console without vc_data", " - clocksource/drivers/sun5i: Handle error returns from", " devm_reset_control_get_optional_exclusive()", " - drm/rockchip: Test for imported buffers with drm_gem_is_imported()", " - drm/tidss: Drop extra drm_mode_config_reset() call", " - drm/amdgpu: fix integer overflow in amdgpu_gem_align_pitch()", " - drm/radeon: fix integer overflow in radeon_align_pitch()", " - drm/radeon: fix memory leak in radeon_ring_restore() on lock failure", " - libbpf: Report error when a negative kprobe offset is specified", " - Documentation: proc: fix section numbering in table of contents", " - arm64: dts: rockchip: Fix gmac0 reset pin for NanoPi R5S", " - arm64: dts: qcom: sdm845-mezzanine: Fix camss ports unit_address_vs_reg", " warning", " - wifi: cfg80211: fix grammar in MLO group key error message", " - arm64: tegra: Fix Tegra234 MGBE PTP clock", " - dt-bindings: pinctrl: nvidia,tegra234: Add missing required block", " - drm/amdkfd: Validate CRIU-restored IDs before idr_alloc", " - driver core: use READ_ONCE() for dev->driver in dev_has_sync_state()", " - wifi: rtw89: Correct data type for scan index to avoid infinite loop", " - wifi: rtw88: fix OOB read from firmware RX descriptor exceeding DMA", " buffer", " - kconfig: fix potential NULL pointer dereference in conf_askvalue", " - wifi: ath9k: fix OOB access from firmware tx status queue ID", " - ARM: dts: am335x-sl50: Fix audio bitclock and frame master endpoint", " - watchdog: sp5100_tco: Use EFCH MMIO for newer Hygon FCH", " - watchdog: sama5d4_wdt: Fix WDDIS detection on SAM9X60 and SAMA7G5", " - watchdog: sprd_wdt: Remove redundant sprd_wdt_disable() on register", " failure", " - media: cedrus: Fix failure to clean up hardware on probe failure", " - media: v4l2-common: Add YUV24 format info", " - pinctrl: sunxi: fix regulator leak in sunxi_pmx_request() error path", " - arm64: dts: rockchip: fix rk809 interrupt pin on rk3566-roc-pc", " - arm64: dts: imx8x-colibri: Correct SODIMM PAD settings", " - vxlan: Fix potential null-ptr-deref in vxlan_gro_prepare_receive().", " - crypto: atmel-sha204a - fix blocking and non-blocking rng logic", " - crypto: ecrdsa - fix unknown OID check in ecrdsa_param_curve", " - crypto: asymmetric_keys - fix OOB read in pefile_digest_pe_contents", " - dlm: fix add msg handle in send_queue ordered", " - nilfs2: fix backing_dev_info reference leak", " - iommu/amd: Fix a stale comment about which legacy mode is user visible", " - arm64: dts: mediatek: mt8192-asurada: Move PCIe DMA bounce buffer to", " host", " - arm64: dts: qcom: sm8450: Fix ICE reg size", " - drm/hisilicon/hibmc: use clock to look up the PLL value", " - evm: terminate and bound the evm_xattrs read buffer", " - thermal: hwmon: Fix critical temperature attribute removal", " - clk: scpi: Unregister child clock providers on remove", " - net/sched: sch_hfsc: annotate data-races in hfsc_dump_class_stats()", " - crypto: ccp - Treat zero-length cert chain as query for blob lengths", " - spi: hisi-kunpeng: Use dev_err_probe() for host registration failure", " - net/sched: sch_htb: do not change sch->flags in htb_dump()", " - net/sched: sch_htb: annotate data-races (I)", " - ipv6: addrconf: bail out of dad_failure when state is no longer POSTDAD", " - IB/mlx5: Fix transport-domain rollback and initialize lb mutex earlier", " - RDMA/hns: Fix arithmetic overflow in calc_hem_config()", " - RDMA/mlx5: Fix devx subscribe-event unwind NULL dereference", " - RDMA/srpt: fix integer overflow in immediate data length check", " - media: atomisp: Fix memory leak in atomisp_fixed_pattern_table()", " - firmware: arm_scmi: Read sensor config as 32-bit value", " - sysfs: clamp show() return value in sysfs_kf_read()", " - regulator: dt-bindings: mt6359: Drop regulator-name pattern restrictions", " - net/sched: sch_drr: annotate data-races around cl->deficit", " - firmware: arm_scmi: Fix OOB in scmi_power_name_get()", " - arm64: dts: qcom: sm8450: Add power-domain and iface clk for ice node", " - tracing: Bound synthetic-field strings with seq_buf", " - device property: fix fwnode reference leak in", " fwnode_graph_get_endpoint_by_id()", " - driver core: Use mod_delayed_work to prevent lost deferred probe work", " - cpufreq: Documentation: fix sampling_down_factor range", " - cpufreq: conservative: Simplify frequency limit handling", " - pwm: imx27: Fix variable truncation in .apply()", " - bus: sunxi-rsb: Always check register address validity", " - RDMA/irdma: Fix out-of-bounds write in irdma_copy_user_pgaddrs", " - RDMA/rxe: Fix a use-after-free problem in rxe_mmap", " - IB/mlx4: Fix refcount leak in add_port() error path", " - RDMA/hns: Fix warning in poll cq direct mode", " - RDMA/counter: Fix incorrect port index in rdma_counter_init() error", " cleanup", " - MIPS: Fix big-endian stack argument fetching in o32 wrapper", " - MIPS: DEC: Remove do_IRQ() call indirection", " - mips: ralink: mt7621: add missing __iomem", " - mips: n64: add __iomem for writel call", " - mtd: spi-nor: Drop duplicate Kconfig dependency", " - ALSA: seq: midi: Serialize output teardown with event_input", " - pinctrl: cs42l43: Fix polarity on debounce", " - nvme-multipath: fix flex array size in struct nvme_ns_head", " - workqueue: drop spurious '*' from print_worker_info() fn declaration", " - ipv6: guard against possible NULL deref in __in6_dev_stats_get()", " - net/sched: cls_bpf: prevent unbounded recursion in offload rollback", " - drm/tegra: gr2d/gr3d: Initialize address register map before HOST1X", " client is registered", " - drm/tegra: gr2d/gr3d: Contain PM in the gr*d_probe/gr*d_remove", " - gpu: host1x: Allow entries in BO caches to be freed", " - drm/tegra: dc: Fix device node reference leak in tegra_dc_has_output()", " - gpu: host1x: Fix iommu_map_sgtable() return value check", " - drm/tegra: Fix iommu_map_sgtable() return value check", " - drm/nouveau/bios: specify correct display fuse register for Ampere and", " Ada", " - libbpf: Harden parse_vma_segs() path parsing", " - libbpf: Fix UAF in strset__add_str()", " - dax/kmem: account for partial discontiguous resource upon removal", " - rapidio/tsi721: prevent a bad dereference in tsi721_db_dpc()", " - ocfs2: don't BUG_ON an invalid journal dinode", " - ocfs2: kill osb->system_file_mutex lock", " - crypto: hisilicon/qm - disable error report before flr", " - drm/msm/dp: fix HPD state status bit shift value", " - drm/msm/dp: Fix the ISR_* enum values", " - EDAC/{skx_common,skx}: Fix UBSAN shift-out-of-bounds in", " skx_get_dimm_info", " - RDMA/rxe: Fix TOCTOU heap overflow in get_srq_wqe", " - RDMA/rxe: Copy WQE to local buffer in non-SRQ receive path", " - media: qcom: venus: drop extra padding in NV12 raw size calculation", " - media: qcom: venus: relax encoder frame/blur dimension steps on v4", " - media: qcom: venus: relax encoder frame/blur step size on v6", " - rpmsg: use generic driver_override infrastructure", " - md/raid10: reset read_slot when reusing r10bio for discard", " - RDMA/siw: bound Read Response placement to the RREAD length", " - block: skip sync_blockdev() on surprise removal in bdev_mark_dead()", " - crypto: algif_skcipher - force synchronous processing", " - crypto: crypto4xx - Remove insecure and unused rng_alg", " - crypto: hisi-trng - Remove crypto_rng interface", " - bpf: Restrict JIT predictor flush to cBPF", " - bpf: Skip redundant IBPB in pack allocator", " - bpf: Prefer packs that won't trigger an IBPB flush on allocation", " - bpf: Prefer dirty packs for eBPF allocations", " - clk: scmi: Fix clock rate rounding", " - drm/hisilicon/hibmc: move display contrl config to hibmc_probe()", " - bitops: use common function parameter names", " - media: rockchip: rga: fix too small buffer size", " - ext4: fix LOGFLUSH shutdown ordering to allow ordered-mode data", " writeback", " - ASoC: rsnd: Fix RSND_SOC_MASK width to single nibble", " - ARM: imx3: Fix CCM node reference leak", " - HID: wiimote: Fix table layout and whitespace errors", " - ata: libata: Fix ata_exec_internal()", " - ARM: imx31: Fix IIM mapping leak in revision check", " - nvdimm/btt: Handle preemption in BTT lane acquisition", " - scsi: Revert \"scsi: Fix sas_user_scan() to handle wildcard and multi-", " channel scans\"", " - scsi: pm8001: Fix error code in non_fatal_log_show()", " - scsi: ufs: Fix wrong value printed in unexpected UPIU response case", " - bpf: fix UAF by restoring RCU-delayed inode freeing in bpffs", " - mm/fake-numa: fix under-allocation detection in uniform split", " - ext2: fix ignored return value of generic_write_sync()", " - sched: restore timer_slack_ns when resetting RT policy on fork", " - lib/test_meminit: use && for bools", " - configfs_lookup(): don't leave ->s_dentry dangling on failure", " - drm/amdgpu: set sub_block_index for mca ras sub-blocks", " - bpftool: Use libbpf error code for flow dissector query", " - perf/x86/amd/core: Always use the NMI latency mitigation", " - ocfs2: rebase copied fsdlm LVB pointers in locking_state", " - ocfs2: fix buffer head management in ocfs2_read_blocks()", " - ocfs2: reject FITRIM ranges shorter than a cluster", " - ocfs2/dlm: require a ref for locking_state debugfs open", " - ocfs2: fix race between ocfs2_control_install_private() and", " ocfs2_control_release()", " - netfilter: nfnetlink_osf: fix mss parsing on big-endian architectures", " - netfilter: synproxy: protect nf_ct_seqadj_init() with conntrack lock", " - netfilter: conntrack: revert ct extension genid infrastructure", " - netfilter: conntrack: call nf_ct_gre_keymap_destroy() if master helper", " is pptp", " - IB/cm: Fix av cm device leak on an error path in cm_init_av_by_path()", " - RDMA/irdma: Fix OOB read during CQ MR registration", " - RDMA/irdma: Initialize iwmr->access during MR registration", " - arm64: dts: tqma8mpql-mba8mpxl: configure sai clock in audio codec as", " well", " - bpf: Check tail zero of bpf_prog_info", " - bpf: Update transport_header when encapsulating UDP tunnel in lwt", " - wifi: wcn36xx: fix heap overflow from oversized firmware HAL response", " - wifi: wcn36xx: fix OOB read from firmware count in PRINT_REG_INFO", " indication", " - wifi: wcn36xx: fix OOB read from short trigger BA firmware response", " - ALSA: seq: Fix partial userptr event expansion", " - riscv: stacktrace: Remove bogus -0x4 offset in non-FP walk_stackframe", " - ALSA: seq: Clear variable event pointer on read", " - ACPI: IPMI: Fix message kref handling on dead device", " - cpufreq: Documentation: fix conservative governor freq_step description", " - IB/mlx5: Don't take the rereg_mr fallback without a new translation", " - IB/mlx5: Properly support implicit ODP rereg_mr", " - spi: ep93xx: fix double-free of zeropage on DMA setup failure", " - firmware_loader: Fix recursive lock in device_cache_fw_images()", " - configfs: fix lockless traversals of ->s_children", " - watchdog: unregister PM notifier on watchdog unregister", " - scsi: target: Fix hexadecimal CHAP_I handling", " - scsi: target: Remove tcm_loop target reset handling", " - pinctrl: mediatek: mt8516: Fix Schmitt trigger register offset of pins", " 34-39", " - pinctrl: mediatek: mt8167: Fix Schmitt trigger register offset of pins", " 34-39", " - vmalloc: fix NULL pointer dereference in is_vm_area_hugepages()", " - hwspinlock: qcom: avoid uninitialized struct members", " - sched/fair: Fix cpu_util runnable_avg arithmetic", " - wifi: mt76: fix argument to ieee80211_is_first_frag()", " - wifi: mt76: mt7915: fix potential tx_retries underflow", " - wifi: mt76: mt7921: fix potential tx_retries underflow", " - btrfs: fix invalid pointer dereference in __btrfs_run_delayed_refs()", " - fbdev: sm501fb: Fix buffer errors in OF binding code", " - hwmon: (it87) Clamp negative values to zero in set_fan()", " - btrfs: zoned: don't account data relocation space-info in statfs free", " space", " - IB/mlx4: Fill in the access_flags if IB_MR_REREG_ACCESS is not specified", " - spi: meson-spifc: fix runtime PM leak on remove", " - ASoC: codecs: aw88261: fix incorrect masks for boost regs", " - vduse: hold vduse_lock across IDR lookup in open path", " - vhost/vdpa: validate virtqueue index in mmap and fault paths", " - vduse: Requeue failed read to send_list head", " - vhost/net: complete zerocopy ubufs only once", " - tools/virtio: check mmap return value in vringh_test", " - ASoC: cs35l56: Fix missing calls to wm_adsp2_remove()", " - ASoC: cs35l56: Don't leave parent IRQ disabled if system_suspend fails", " - bonding: 3ad: fix mux port state on oper down", " - ext4: fix kernel BUG in ext4_write_inline_data_end", " - selftests/bpf: Fix bpf_iter/task_vma test", " - cxl/test: Fix integer overflow in mock LSA bounds checks", " - cxl/test: Zero out LSA backing memory to avoid leaking to user", " - of: cpu: add check in __of_find_n_match_cpu_property()", " - bpf: Tighten cgroup storage cookie checks for prog arrays", " - s390/process: Fix kernel thread function pointer type", " - Bluetooth: hci_qca: fix NULL pointer dereference in qca_dmp_hdr() for", " non-serdev device", " - Bluetooth: hci: validate codec capability element length", " - Bluetooth: vhci: validate devcoredump state before side effects", " - fs: efs: remove unneeded debug prints", " - RDMA/mlx5: Remove raw RSS QP restrack tracking", " - RDMA/mlx5: Fix undefined shift of user RQ WQE size", " - RDMA/mlx5: Release the HW‑provided UAR index rather than the SW one", " - ASoC: codecs: hdac_hdmi: Validate written enum value", " - ASoC: fsl: fsl_audmix: Validate written enum values", " - ASoC: tegra: tegra210_ahub: Validate written enum value", " - net/sched: cls_flow: Dont expose folded kernel pointers", " - net: fib_rules: Don't dump dying fib_rule in fib_rules_dump().", " - bridge: cfm: reject invalid CCM interval at configuration time", " - sctp: validate embedded address parameter length", " - net/sched: sch_hfsc: Don't make class passive twice", " - tipc: require net admin for TIPCv2 netlink mutators", " - tipc: prevent snt_unacked underflow on CONN_ACK", " - tipc: reject inverted service ranges from peer bindings", " - cxl/test: Add check after kzalloc() memory in alloc_mock_res()", " - crypto: marvell/octeontx - fix DMA cleanup using wrong loop index", " - crypto: cavium/cpt - fix DMA cleanup using wrong loop index", " - crypto: rng - Free default RNG on module exit", " - spi: xilinx: use FIFO occupancy register to determine buffer size", " - ASoC: adau1372: Clear PLL_EN on failed PLL lock without reset GPIO", " - power: supply: core: fix supplied_from allocations", " - handshake: Require admin permission for DONE command", " - net/sched: sch_fq_codel: Do not call qdisc_tree_reduce_backlog during", " peek before restoring qlen", " - net/sched: sch_codel: Do not call qdisc_tree_reduce_backlog during peek", " before restoring qlen", " - net: mana: initialize gdma queue id to INVALID_QUEUE_ID", " - net: mana: guard TX wq object destroy with INVALID_MANA_HANDLE check", " - bpf: Run generic devmap egress prog on private skb", " - net/mlx5: Check max_macs devlink param value against max capability", " - net: wwan: t7xx: check skb_clone in control TX", " - net: bcmgenet: Use weighted round-robin TX DMA arbitration", " - kcm: use WRITE_ONCE() when changing lower socket callbacks", " - netfilter: nf_conncount: callers must hold rcu read lock", " - ALSA: core: Fix unintuitive behavior of snd_power_ref_and_wait()", " - cifs: remove all cifs files before kill super", " - smb/client: always return a value for FS_IOC_GETFLAGS", " - selftests/bpf: Initialize operation name before use", " - bpf: Fix bpf_get/setsockopt to tos for ipv4-mapped ipv6 socket", " - bpf, sockmap: reject overflowing copy + len in bpf_msg_push_data()", " - bpf, sockmap: fix integer overflow in bpf_msg_pop_data() bounds check", " - MIPS: mm: Fix out-of-bounds write in maar_res_walk()", " - powerpc/perf: fix preempt count underflow in fsl_emb_pmu_del", " - powerpc/powernv: fix preempt count leak in", " pnv_kexec_wait_secondaries_down", " - powerpc/kexec: fix double get_cpu() imbalance in kexec_prepare_cpus", " - KEYS: Use acquire when reading state in keyring search", " - tipc: fix UAF in tipc_l2_send_msg()", " - tcp: ipv6: clamp default adverting MSS to avoid GSO_BY_FRAGS (0xFFFF)", " - ionic: Fix check in ionic_get_link_ext_stats", " - ksmbd: fix use-after-free in same_client_has_lease()", " - mfd: cs42l43: Sanity check firmware size", " - ocfs2: fix circular locking dependency in ocfs2_dio_end_io_write", " - net/9p: fix race condition on rdma->state in trans_rdma.c", " - staging: nvec: fix use-after-free in nvec_rx_completed()", " - coresight: cti: Fix DT filter signals silently ignored", " - coresight: etm4x: Correct TRCVMIDCCTLR1 save and restore", " - PCI/ASPM: Don't reconfigure ASPM entering low-power state", " - PCI: Introduce named defines for PCI ROM", " - PCI: Check ROM header and data structure addr before accessing", " - x86/platform/olpc: xo15: Drop wakeup source on driver removal", " - platform/x86: xo15-ebook: Fix wakeup source and GPE handling", " - PCI: loongson: Do not ignore downstream devices on external bridges", " - bus: mhi: ep: Fix potential deadlock in mhi_ep_reset_worker()", " - phy: phy-can-transceiver: Check driver match and driver data against", " NULL", " - mailbox: mtk-adsp: fix UAF during device teardown", " - staging: most: video: avoid double free on video register failure", " - usb: host: max3421: Fix shift-out-of-bounds in max3421_hub_control()", " - usb: host: max3421: Reject hub port requests for non-existent ports", " - char: tlclk: fix use-after-free in tlclk_cleanup()", " - iio: light: si1133: reset counter to prevent race condition", " - iio: light: si1133: prevent race condition on timeout", " - iio: magnetometer: ak8975: fix potential kernel stack memory leak", " - iio: adc: xilinx-ams: fix out-of-bounds channel lookup in event handling", " - iio: accel: mma8452: handle I2C read error(s) in mma8452_read()", " - iio: tcs3472: power down chip on probe failure", " - clk: at91: keep securam node alive while mapping it", " - HID: logitech-hidpp: remove excess kernel-doc member in", " hidpp_scroll_counter", " - fs/ntfs3: add bounds check to run_get_highest_vcn()", " - fs/ntfs3: fix mount failure on 64K page-size kernels", " - dmaengine: imx-sdma: Refine spba bus searching in probe", " - perf: Fix off-by-one stack buffer overflow in kallsyms__parse()", " - dmaengine: qcom: gpi: set DMA_PRIVATE capability", " - dmaengine: Fix possible use after free", " - clk: qcom: a53: Corrected frequency multiplier for 1152MHz", " - pNFS/filelayout: fix cheking if a layout is striped", " - xprtrdma: Remove temp allocation of rpcrdma_rep objects", " - xprtrdma: Avoid 250 ms delay on backlog wakeup", " - xprtrdma: Close lost-wakeup race in xprt_rdma_alloc_slot", " - xprtrdma: Post receive buffers after RPC completion", " - xprtrdma: Use sendctx DMA state for Send signaling", " - xprtrdma: Decouple req recycling from RPC completion", " - NFSv4/pnfs: defer return_range callbacks until after inode unlock", " - nfs: keep PG_UPTODATE clear after read errors in page groups", " - NFSv4/flexfiles: honor FF_FLAGS_NO_IO_THRU_MDS on fatal DS connect", " errors", " - PCI: mediatek: Fix operator precedence in PCIE_FTS_NUM_L0 macro", " - PCI: meson: Propagate devm_add_action_or_reset() failure", " - fs/ntfs3: resize log->one_page_buf when adopting on-disk page size", " - PCI: rcar-host: Remove unused LIST_HEAD(res)", " - xprtrdma: Check frwr_wp_create() during connect", " - xprtrdma: Document and assert reply-handler invariants", " - xprtrdma: Resize reply buffers before reposting receives", " - xprtrdma: Fix bcall rep leak and unbounded peek", " - xprtrdma: Sanitize the reply credit grant after parsing", " - xprtrdma: Repost Receive buffers for malformed replies", " - xprtrdma: Return sendctx slot after Send preparation failure", " - tools lib api: Fix missing null termination in filename__read_int/ull()", " - tools lib api: Fix filename__write_int() writing uninitialized stack", " data", " - tools lib api: Fix mount_overload() snprintf truncation and toupper", " range", " - PCI: mediatek: Fix possible truncation in mtk_pcie_parse_port()", " - PCI: mediatek: Use actual physical address instead of virt_to_phys()", " - security/apparmor/apparmorfs.c: conditionally compile", " get_loaddata_common_ref()", " - apparmor: aa_label_alloc use aa_label_free on alloc failure", " - apparmor: fix rawdata_f_data implicit flex array", " - apparmor: fix potential UAF in aa_replace_profiles", " - apparmor: aa_getprocattr free procattr leak on format failure", " - apparmor: put secmark label after secid lookup", " - i3c: master: Prevent reuse of dynamic address on device add failure", " - apparmor: fix label can not be immediately before a declaration", " - sparc: led: avoid trimming a newline from empty writes", " - gpio: mlxbf3: fail probe if gpiochip registration fails", " - spi: dw: fix wrong BAUDR setting after resume", " - xfrm: Support crypto offload for inbound IPv6 ESP packets not in GRO", " path", " - xfrm: annotate data-races around xfrm_policy_count[] and", " xfrm_policy_default[]", " - xfrm: validate selector family and prefixlen during match", " - ASoC: tlv320aic3x: restrict CLKDIV bypass Q values in dual-rate mode", " - drm/amdkfd: Avoid double-unpin of DOORBELL/MMIO BOs on free", " - drm/amdkfd: fix list_del corruption in kfd_criu_resume_svm", " - octeontx2-pf: Fix leak of SQ timestamp buffer on teardown", " - net: psample: fix info leak in PSAMPLE_ATTR_DATA", " - sctp: hold socket lock when dumping endpoints in sctp_diag", " - PCI: iproc: Restore .map_irq() for the platform bus driver", " - spi: rpc-if: Use correct device for hardware reinitialization on resume", " - virtio-net: fix len check in receive_big()", " - devlink: Fix parent ref leak in devl_rate_node_create()", " - flow_dissector: check device type before reading ETH_ADDRS", " - ALSA: usb-audio: Kill MIDI 2.0 URBs before freeing endpoints", " - arm64/hw_breakpoint: reject unaligned watchpoints that would truncate", " BAS", " - thermal: intel: Fix dangling resources on thermal_throttle_online()", " failure", " - ACPI: resource: Amend kernel-doc style", " - ACPI: IPMI: Fix inverted interface check in ipmi_bmc_gone()", " - ieee802154: Remove WARN_ON() in cfg802154_pernet_exit()", " - ieee802154: fix kernel-infoleak in dgram_recvmsg()", " - md/raid1: free r1_bio when REQ_NOWAIT is set and read would block on", " retry", " - netfilter: ipset: Fix data race between add and dump in all hash types", " - netfilter: ipset: annotate \"pos\" for concurrent readers/writers", " - netfilter: ipset: Don't use test_bit() in lockless RCU readers in hash", " types", " - netfilter: ipset: fix order of kfree_rcu() and rcu_assign_pointer()", " - netfilter: nf_reject: skip iphdr options when looking for icmp header", " - netfilter: nft_meta_bridge: fix NFT_META_BRI_IIFPVID stack leak", " - irqchip/crossbar: Fix parent domain resource leak", " - selftests/mm: clarify alternate unmapping in compaction_test", " - selftests/mm: allow PUD-level entries in compound testcase of hmm tests", " - selftests/mm: fix exclusive_cow test fork() handling", " - net: marvell: prestera: initialize err in prestera_port_sfp_bind", " - tipc: fix use-after-free of the discoverer in tipc_disc_rcv()", " - net: ethernet: mtk_ppe: Fix rhashtable leak in mtk_ppe_init error paths", " - octeontx2-af: mcs: Fix unsupported secy stats read", " - octeontx2-pf: Clear stats of all resources when freeing resources", " - octeontx2-pf: mcs: Fix mcs resources free on PF shutdown", " - rtc: abx80x: fix the RTC_VL_CLR clearing all status flags", " - rtc: ds1307: handle oscillator stop flag for ds1337/ds1339/ds3231", " - bpf: Fix stack slot index in nospec checks", " - bpf: zero-initialize the fib lookup flow struct", " - bpf: Fix effective prog array index with BPF_F_PREORDER", " - drm/edid: fix OOB read in drm_parse_tiled_block()", " - PCI: endpoint: pci-epf-vntb: Add check to detect 'db_count' value of 0", " - PCI: endpoint: pci-epf-ntb: Add check to detect 'db_count' value of 0", " - ice: fix FDIR CTRL VSI resource leak in ice_reset_all_vfs()", " - ice: fix AQ error code comparison in ice_set_pauseparam()", " - i40e: Fix i40e_debug() to use struct i40e_hw argument", " - rtc: msc313: fix NULL deref in shared IRQ handler at probe", " - ksmbd: fix use-after-free of conn->preauth_info in concurrent SMB2", " NEGOTIATE", " - ipv6: Fix null-ptr-deref in fib6_nh_mtu_change().", " - ipv4: fib: Don't ignore error route in local/main tables.", " - bpf, lsm: Add disabled BPF LSM hook list", " - bpf: Disable xfrm_decode_session hook attachment", " - netfilter: nf_nat: avoid invalid nat_net pointer use on failed", " nf_nat_init()", " - netfilter: nf_conncount: prevent connlimit drops for early confirmed ct", " - netfilter: nft_synproxy: stop bypassing the priv->info snapshot", " - netfilter: nft_compat: ebtables emulation must reject non-bridge targets", " - NTB: epf: Make db_valid_mask cover only real doorbell bits", " - NTB: epf: Report 0-based doorbell vector via ntb_db_event()", " - NTB: epf: Fix doorbell bitmask and IRQ vector handling", " - alpha/PCI: Add security_locked_down() check to pci_mmap_resource()", " - alpha/PCI: Fix __pci_mmap_fits() overflow for zero-length BARs", " - net, bpf: check master for NULL in xdp_master_redirect()", " - net: dsa: sja1105: round up PTP perout pin duration", " - veth: fix NAPI leak in XDP enable error path", " - net/sched: cls_api: Handle TC_ACT_CONSUMED in tcf_qevent_handle", " - ipv6: fix error handling in disable_ipv6 sysctl", " - ipv6: fix error handling in ignore_routes_with_linkdown sysctl", " - ipv6: fix error handling in forwarding sysctl", " - ipv6: fix error handling in disable_policy sysctl", " - smb/client: preserve errors from smb2_set_sparse()", " - rtc: ds1307: Fix off-by-one issue with wday for rx8130", " - rtc: cmos: unregister HPET IRQ handler on probe failure", " - net: mvneta: re-enable percpu interrupt on resume", " - net: sungem: fix probe error cleanup", " - net: ethernet: sunplus: spl2sw: fix phy_node refcount leak in remove", " - ASoC: fsl_asrc_dma: fix eDMA maxburst misalignment with channel count", " - dt-bindings: net: renesas,ether: Drop example \"ethernet-phy-", " ieee802.3-c22\" fallback", " - tracing: probes: fix typo in a log message", " - spi: sh-msiof: abort transfers when reset times out", " - gpio: mvebu: fail probe if gpiochip registration fails", " - gpio: htc-egpio: use managed gpiochip registration", " - seg6: validate SRH length before reading fixed fields", " - qede: fix out-of-bounds check for cqe->len_list[]", " - net: enetc: check the number of BDs needed for xdp_frame", " - sctp: fix SCTP_RESET_STREAMS stream list length limit", " - MIPS: DEC: Ensure RTC platform device deregistration upon failure", " - hwmon: adm1275: Prevent reading uninitialized stack", " - hwmon: (pmbus) Fix passing events to regulator core", " - usbnet: gl620a: fix out-of-bounds read in genelink_rx_fixup()", " - NFSv4/flexfiles: honor FF_FLAGS_NO_IO_THRU_MDS in", " pg_get_mirror_count_write", " - apparmor: check label build before no_new_privs test", " - apparmor: grab ns lock and refresh when looking up changehat child", " profiles", " - drm/amdgpu: initialize irq.lock spinlock earlier", " - dpaa2-switch: fix VLAN upper check not rejecting bridge join", " - net: phy: sfp: free mii_bus in sfp_i2c_mdiobus_destroy", " - net: gianfar: dispose irq mappings on probe failure and device removal", " - net/sched: sch_teql: Introduce slaves_lock to avoid race condition and", " UAF", " - bridge: stp: Fix a potential use-after-free when deleting a bridge", " - tracing/events: Fix to check the simple_tsk_fn creation", " - tracing: eprobe: read the complete FILTER_PTR_STRING pointer", " - irqchip/gic-v3-its: Fix OF node reference leak", " - irqchip/ts4800: Fix missing chained handler cleanup on remove", " - cxgb4: Fix decode strings dump for T6 adapters", " - virtio_net: disable cb when NAPI is busy-polled", " - net/sched: act_bpf: use rcu_dereference_bh() to read the filter", " - ksmbd: reject undersized DACLs before parsing ACEs", " - gpio: timberdale: Return -ENOMEM on dynamic memory allocation in probe", " - pinctrl: meson: restore non-sleeping GPIO access", " - net/sched: hhf: clear heavy-hitter state on reset", " - fs: refuse O_TMPFILE creation with an unmapped fsuid or fsgid", " - afs: Fix error code in afs_extract_vl_addrs()", " - afs: use kvfree() to free memory allocated by kvcalloc()", " - afs: Fix callback service message parsers to pass through -EAGAIN", " - afs: Fix vllist leak", " - afs: Fix the volume AFS_VOLUME_RM_TREE is set on", " - afs: Fix unchecked-length string display in debug statement", " - minix: avoid overflow in bitmap block count calculation", " - ata: sata_gemini: unwind clocks on IDE pinctrl errors", " - HID: picolcd: prevent NULL pointer dereference in", " picolcd_send_and_wait()", " - HID: core: Fix OOB read in hid_get_report for numbered reports", " - arm64/mm: convert READ_ONCE(*ptep) to ptep_get(ptep)", " - arm64/mm: convert set_pte_at() to set_ptes(..., 1)", " - arm64/mm: convert ptep_clear() to ptep_get_and_clear()", " - arm64/mm: Optimize TLB flush in unmap_hotplug_[pmd|pud]_range()", " - selftests/hid: convert the hid_bpf selftests with struct_ops", " - selftests/hid: Cover hid_bpf_get_data() size overflow", " - net: usb: net1080: validate packet_len before pad-byte access in", " rx_fixup", " - gue: validate REMCSUM private option length", " - netfilter: xt_u32: reject invalid shift counts", " - netfilter: xt_rateest: fix u64 truncation in xt_rateest_mt()", " - netfilter: ip6tables: mark malformed IPv6 extension headers for hotdrop", " - netfilter: xt_connmark: reject invalid shift parameters", " - net/mlx5e: Fix HV VHCA stats zero-sized buffer allocation", " - net/mlx5e: Fix HV VHCA stats agent registration race", " - net: microchip: vcap: fix races on the shared Super VCAP block", " - qede: fix off-by-one in BD ring consumption on build_skb failure", " - net: qualcomm: rmnet: validate MAP frame length before ingress parsing", " - net/sched: act_pedit: fix TOCTOU heap OOB write in tc offload", " - net/smc: fix UAF in smc_cdc_rx_handler() by pinning the socket", " - amt: fix size calculation in amt_get_size()", " - Bluetooth: 6lowpan: hold L2CAP conn across debugfs control", " - Bluetooth: MGMT: Fix adv monitor add failure cleanup", " - Bluetooth: ISO: exclude RFU bits from ISO_SDU_Length", " - Bluetooth: bpa10x: avoid OOB read of revision string in bpa10x_setup()", " - ring-buffer: Fix event length with forced 8-byte alignment", " - net/tls: Consume empty data records in tls_sw_read_sock()", " - net: usb: lan78xx: move functions to avoid forward definitions", " - net: usb: lan78xx: disable VLAN filter in promiscuous mode", " - net/sched: cake: reject overhead values that underflow length", " - octeontx2-pf: check DMAC extraction support before filtering", " - ipv4: igmp: Fix potential UAF in igmp_gq_start_timer()", " - ipv6: mcast: Replace locking comments with lockdep annotations.", " - ipv6: mcast: Fix potential UAF in MLD delayed work", " - ipvs: pass parsed transport offset to state handlers", " - ipvs: use parsed transport offset in TCP state lookup", " - ipvs: fix PMTU for GUE/GRE tunnel ICMP errors", " - ipvs: ensure inner headers in ICMP errors are in headroom", " - s390/zcrypt: Remove the empty file", " - cifs: validate DFS referral string offsets", " - SUNRPC: release lower rpc_clnt if killed waiting for XPRT_LOCKED", " - SUNRPC: pin upper rpc_clnt across the TLS connect_worker", " - dm era: fix NULL pointer dereference in metadata_open()", " - regulator: core: regulator_lock_two() should test for EDEADLK not", " EDEADLOCK", " - selftests/net: fix EVP_MD_CTX leak in tcp_mmap", " - net/mlx5: Fix L3 tunnel entropy refcount leak", " - octeontx2-af: fix VF bringup affecting PF promiscuous state", " - smb: client: fix overflow in passthrough ioctl bounds check", " - mlxsw: fix refcount leak in mlxsw_sp_port_lag_join()", " - mlxsw: fix refcount leak in mlxsw_sp_vrs_lpm_tree_replace()", " - vduse: Fix race in vduse_dev_msg_sync and vduse_dev_read_iter", " - ASoC: SOF: ipc4-control: Fix TOCTOU in sof_ipc4_bytes_put", " - ASoC: SOF: ipc3-control: Use overflow checks in control_update size calc", " - ASoC: SOF: ipc3-control: Fix TOCTOU in bytes_put and bytes_get", " - ASoC: SOF: topology: validate vendor array size before parsing", " - net: qrtr: fix 32-bit integer overflow in qrtr_endpoint_post()", " - net: atm: reject out-of-range traffic classes in QoS validation", " - net: ife: require ETH_HLEN to be pullable in ife_decode()", " - arm64: fpsimd: Fix type mismatch in sve_{save,load}_state()", " - arm64: dts: qcom: sdm630: describe adsp_mem region properly", " - KVM: s390: pci: Fix GISC refcount leak on AIF enable failure", " - KVM: arm64: vgic: Check the interrupt is still ours before migrating it", " - KVM: s390: pci: Fix handling of AIF enable without AISB", " - KVM: x86: Ignore pending PV EOI if the vCPU has since disabled PV EOIs", " - fbdev: metronomefb: fix potential memory leak in metronomefb_probe()", " - fbdev: broadsheetfb: fix potential memory leak in broadsheetfb_probe()", " - fbdev: hecubafb: fix potential memory leak in hecubafb_probe()", " - fbdev: sm712: Fix operator precedence in big_swap macro", " - fbdev: radeon: fix potential memory leak in radeonfb_pci_register()", " - fbdev: i740fb: fix potential memory leak in i740fb_probe()", " - fbdev: s3fb: fix potential memory leak in s3_pci_probe()", " - fbdev: uvesafb: fix potential memory leak in uvesafb_probe()", " - fbdev: tdfxfb: fix potential memory leak in tdfxfb_probe()", " - fbdev: carminefb: fix potential memory leak in alloc_carmine_fb()", " - fbdev: vesafb: fix memory leak in vesafb_probe()", " - fbdev: nvidia: fix potential memory leak in nvidiafb_probe()", " - fbdev: tridentfb: fix potential memory leak in trident_pci_probe()", " - ASoC: SOF: ipc3-control: Fix heap overflow in bytes_ext put/get", " - ASoC: SOF: ipc3-control: Validate size in snd_sof_update_control", " - ASoC: mediatek: mt8192: Release reserved memory on cleanup", " - ASoC: mediatek: mt8183: Release reserved memory on cleanup", " - ASoC: qcom: q6apm: fix NULL pointer dereference in graph_callback", " - netfilter: nf_conntrack_irc: fix parse_dcc() off-by-one OOB read", " - netfilter: nfnl_cthelper: apply per-class values when updating policies", " - netfilter: xt_cluster: reject template conntracks in hash match", " - netfilter: nf_queue: pin bridge device while NFQUEUE holds fake dst", " - netfilter: nf_nat_sip: reload possible stale data pointer", " - netfilter: nf_conntrack_reasm: guard mac_header adjustment after IPv6", " defrag", " - netfilter: nf_conncount: fix zone comparison in tuple dedup", " - netfilter: ecache: fix inverted time_after() check", " - netfilter: xt_nat: reject unsupported target families", " - netfilter: bridge: fix stale prevhdr pointer in br_ip6_fragment()", " - gpu: host1x: Fix device reference leak in host1x_device_parse_dt() error", " path", " - soc: ti: k3-ringacc: Fix access mode for", " k3_ringacc_ring_pop_tail_io/proxy", " - soc: fsl: qe: panic on ioremap() failure in qe_reset()", " - selinux: check connect-related permissions on TCP Fast Open", " - leds: uleds: Fix potential buffer overread", " - mfd: sm501: Fix reference leak on failed device registration", " - tools/power/x86/intel-speed-select: Harden daemon pidfile open", " - x86/boot: Validate console=uart8250 baud rate to fix early boot hang", " - x86/boot: Reject too long acpi_rsdp= values", " - perf/x86/amd/lbr: Fix kernel address leakage", " - s390/perf_cpum_cf: Add missing array_index_nospec() to", " __hw_perf_event_init()", " - batman-adv: gw: acquire ethernet header only after skb realloc", " - batman-adv: access unicast_ttvn skb->data only after skb realloc", " - batman-adv: dat: acquire ARP hw source only after skb realloc", " - batman-adv: bla: reacquire gw address after skb realloc", " - batman-adv: dat: ensure accessible eth_hdr proto field", " - batman-adv: dat: fix tie-break for candidate selection", " - batman-adv: tt: avoid request storms during pending request", " - batman-adv: fix VLAN priority offset", " - batman-adv: frag: free unfragmentable packet", " - batman-adv: frag: fix primary_if leak on failed linearization", " - batman-adv: tt: prevent TVLV OOB check overflow", " - cifs: invalidate cfid on unlink/rename/rmdir", " - mfd: tps6586x: Fix OF node refcount", " - HID: playstation: validate num_touch_reports in DualShock 4 reports", " - Bluetooth: SCO: fix sleeping under spinlock in sco_conn_ready", " - Bluetooth: SCO: hold sk properly in sco_conn_ready", " - jbd2: fix integer underflow in jbd2_journal_initialize_fast_commit()", " - nvdimm/btt: Free arenas on btt_init() error paths", " - nvdimm/btt: Free arena sub-allocations on discover_arenas() error path", " - sunrpc: pin svc_xprt across the asynchronous TLS handshake callback", " - sunrpc: wait for in-flight TLS handshake callback when cancel loses race", " - lockd: Plug nlm_file leak when nlm_do_fopen() fails", " - lockd: Plug nlm_file refcount leak on cached nlm_do_fopen() failure", " - SUNRPC: Bound-check xdr_buf_to_bvec() stores before writing", " - remoteproc: qcom: Fix leak when custom dump_segments addition fails", " - MIPS: ip22-gio: fix gio device memory leak", " - MIPS: ip22-gio: fix kfree() of static object", " - MIPS: ip22-gio: fix device reference leak in probe", " - MIPS: DEC: Ensure 32-bit stack location for o32 prom_printf()", " - power: supply: cpcap-battery: Fix missing nvmem_device_put() causing", " reference leak", " - mm/damon/core: make charge_addr_from aware of end-address exclusivity", " - fs/ntfs3: fix syncing wrong inode on DIRSYNC cross-directory rename", " - fs/ntfs3: bound DeleteIndexEntryAllocation memmove length", " - fs/ntfs3: bound copy_lcns dp->page_lcns[] index in analysis pass", " - fs/ntfs3: bound attr_off in UpdateResidentValue against data_off", " - fs/ntfs3: validate lcns_follow in log_replay conversion", " - fs/ntfs3: add depth limit to indx_find_buffer to prevent stack overflow", " - fs/ntfs3: bound NTFS_DE view.data_off in", " UpdateRecordData{Root,Allocation}", " - ntfs3: cap RESTART_TABLE free-chain walker at rt->used", " - ntfs3: bound to_move in indx_insert_into_root before hdr_insert_head", " - ntfs3: validate split-point offset in indx_insert_into_buffer", " - ntfs3: fix out-of-bounds read in decompress_lznt", " - power: supply: charger-manager: fix refcount leak in is_full_charged()", " - mips: sched: Fix CPUMASK_OFFSTACK memory corruption", " - riscv: cacheinfo: Fix node reference leak in populate_cache_leaves", " - mm/damon/sysfs-schemes: fix dir put orders in access_pattern_add_dirs()", " - mm/damon/sysfs-schemes: put stats for scheme_add_dirs() internal error", " - proc: only bump parent nlink when registering directories", " - mm/mm_init: fix uninitialized struct pages for ZONE_DEVICE", " - mtd: slram: remove failed entries from the device list", " - 9p: skip nlink update in cacheless mode to fix WARN_ON", " - scsi: smartpqi: Use shost_to_hba() in pqi_scan_finished()", " - scsi: sas: Skip opt_sectors when DMA reports no real optimization hint", " - ocfs2: use kzalloc for quota recovery bitmap allocation", " - mtd: rawnand: pl353: fix probe resource allocation", " - net/9p: fix infinite loop in p9_client_rpc on fatal signal", " - mtd: rawnand: fix condition in 'nand_select_target()'", " - ocfs2: avoid moving extents to occupied clusters", " - ocfs2: fix NULL h_transaction deref in ocfs2_assure_trans_credits", " - ocfs2: add journal NULL check in ocfs2_checkpoint_inode()", " - ocfs2: reject dinodes with non-canonical i_mode type", " - ocfs2: reject dinodes whose i_rdev disagrees with the file type", " - ocfs2: reject non-inline dinodes with i_size and zero i_clusters", " - fpga: dfl: add bounds check in dfh_get_param_size()", " - bus: mhi: ep: Protect mhi_ep_handle_syserr() in the error path", " - net: thunderbolt: Fix frags[] overflow by bounding frame_count", " - fpga: microchip-spi: fix zero header_size OOB read in", " mpf_ops_parse_header()", " - mtd: spi-nor: swp: Improve locking user experience", " - mtd: maps: vmu-flash: fix NULL pointer dereference in initialization", " - irqchip/crossbar: Use correct index in crossbar_domain_free()", " - tpm: tpm_tis_spi: Use wait_woken() in wait_for_tmp_stat()", " - dmaengine: tegra: Fix burst size calculation", " - dmaengine: dw-edma: Add spinlock to protect DONE_INT_MASK and", " ABORT_INT_MASK", " - platform/x86/amd/pmc: Check for intermediate wakeup in function", " - platform/x86/amd/pmc: Delay suspend for some Lenovo Laptops", " - platform/x86/amd/pmc: Add delay_suspend module parameter", " - smb: client: use kvzalloc() for megabyte buffer in simple fallocate", " - ksmbd: fix integer overflow in set_file_allocation_info()", " - hwmon: (ltc2992) add missing 'select REGMAP_I2C' to Kconfig", " - i2c: mediatek: fix WRRD for SoCs without auto_restart option", " - i2c: mlxbf: Fix use-after-free in mlxbf_i2c_init_resource()", " - ice: fix ice_init_link() error return preventing probe", " - xen/gntdev: fix error handling in ioctl", " - xfrm: use compat translator only for u64 alignment mismatch", " - net: ip_gre: require CAP_NET_ADMIN in the device netns for changelink", " - xfrm: xfrm_interface: require CAP_NET_ADMIN in the device netns for", " changelink", " - tpm: fix event_size output in tpm1_binary_bios_measurements_show", " - tpm: Make the TPM character devices non-seekable", " - time: Fix off-by-one in compat settimeofday() usec validation", " - spi: uniphier: Fix completion initialization order before", " devm_request_irq()", " - sctp: validate STALE_COOKIE cause length before reading staleness", " - nvmet-rdma: handle inline data with a nonzero offset", " - can: esd_usb: kill anchored URBs before freeing netdevs", " - can: isotp: use unconditional synchronize_rcu() in isotp_release()", " - can: bcm: defer rx_op deallocation to workqueue to fix thrtimer UAF", " - can: bcm: fix lockless bound/ifindex race and silent RX_SETUP failure", " - can: bcm: add missing rcu list annotations and operations", " - bpf,fork: wipe ->bpf_storage before bailouts that access it", " - bpf: Add missing access_ok call to copy_user_syms", " - net: sparx5: unregister blocking notifier on init failure", " - dm thin metadata: fix superblock refcount leak on snapshot shadow", " failure", " - dm thin metadata: fix metadata snapshot consistency on commit failure", " - dm era: fix out-of-bounds memory access for non-zero start sector", " - dm-bufio: fix wrong count calculation in dm_bufio_issue_discard", " - dm-ioctl: fix a possible overflow in list_version_get_info", " - dm-log: fix a bitset_size overflow on 32bit machines", " - dm-stats: fix dm_jiffies_to_msec64", " - dm-stats: fix merge accounting", " - dm_early_create: fix freeing used table on dm_resume failure", " - dm-integrity: don't increment hash_offset twice", " - dm-verity: fix a possible NULL pointer dereference", " - dm-verity: increase sprintf buffer size", " - scsi: hpsa: Fix DMA mapping leak on IOACCEL2 reset path", " - scsi: lpfc: Fix memory leak in lpfc_sli4_driver_resource_setup()", " - scsi: sg: Report request-table problems when any status is set", " - scsi: xen: scsiback: Free the command tag on the TMR submit-failure path", " - scsi: xen: scsiback: Free unsubmitted command instead of double-putting", " it", " - scsi: target: Bound PR-OUT TransportID parsing to the received buffer", " - scsi: target: core: Fix iSCSI ISID use-after-free in REGISTER AND MOVE", " - scsi: elx: efct: Fix refcount leak in efct_hw_io_abort()", " - scsi: elx: efct: Fix I/O leak on unsupported additional CDB", " - Input: ims-pcu - fix use-after-free and double-free in disconnect", " - Input: ims-pcu - release data interface on disconnect", " - Input: ims-pcu - validate control endpoint type", " - Input: ims-pcu - add response length checks", " - Input: ims-pcu - fix DMA mapping violation in line setup", " - Input: ims-pcu - fix out-of-bounds read in ims_pcu_irq() debug logging", " - Input: ims-pcu - fix potential infinite loop in CDC union descriptor", " parsing", " - Input: ims-pcu - fix race condition in reset_device sysfs callback", " - Input: ims-pcu - fix type confusion in CDC union descriptor parsing", " - net/mlx5e: macsec: fix use-after-free of metadata_dst on RX SC delete", " - posix-cpu-timers: Use u64 multiplication in update_rlimit_cpu()", " - cpu: hotplug: Preserve per instance callback errors", " - cpu: hotplug: Bound hotplug states sysfs output", " - gpio-f7188x: Add support for NCT6126D version B", " - gpios: palmas: add .get_direction() op", " - net: sit: require CAP_NET_ADMIN in the device netns for changelink", " - net: wwan: t7xx: destroy DMA pool on CLDMA late init failure", " - net: ixp4xx_hss: fix duplicate HDLC netdev allocation", " - net/sched: act_ct: preserve tc_skb_cb across defragmentation", " - net: ena: clean up XDP TX queues when regular TX setup fails", " - net: ip6_vti: require CAP_NET_ADMIN in the device netns for changelink", " - net: ip_vti: require CAP_NET_ADMIN in the device netns for changelink", " - net: ipip: require CAP_NET_ADMIN in the device netns for changelink", " - net: ip6_gre: require CAP_NET_ADMIN in the device netns for changelink", " - ieee802154: admin-gate legacy LLSEC dump operations", " - ieee802154: allow legacy LLSEC ADD/DEL ops to pass strict validation", " - ieee802154: ca8210: fix cas_ctl leak on spi_async failure", " - ieee802154: ca8210: fix pointer truncation in kfifo on 64-bit", " - net/sched: sch_teql: move rcu_read_lock()/spin_lock() from _bh variants", " - batman-adv: retrieve ethhdr after potential skb realloc on RX", " - batman-adv: ensure minimal ethernet header on TX", " - batman-adv: clean untagged VLAN on netdev registration failure", " - LoongArch: Fix missing dirty page tracking in {pte,pmd}_wrprotect()", " - espintcp: use sk_msg_free_partial to fix partial send", " - bnx2x: fix potential memory leak in bnx2x_alloc_mem_bp()", " - rtc: mpfs: fix counter upload completion condition", " - hwmon: (w83627hf) remove VID sysfs files on error and remove", " - hwmon: (w83793) remove vrm sysfs file on probe failure", " - net: liquidio: fix BAR resource leak on PF number failure", " - hwmon: (occ) unregister sysfs devices outside occ lock", " - fsl/fman: Free init resources on KeyGen failure in fman_init()", " - net: lan743x: Initialize eth_syslock spinlock before use", " - net/sched: sch_multiq: Replace direct dequeue call with peek and", " qdisc_dequeue_peeked", " - net/sched: sch_taprio: Replace direct dequeue call with peek and", " qdisc_dequeue_peeked", " - tracing/probes: Fix double addition of offset for @+FOFFSET", " - orangefs: keep the readdir entry size 64-bit in fill_from_part()", " - ata: pata_pxa: Fix DMA channel leak on probe error", " - net: wwan: iosm: bound device offsets in the MUX downlink decoder", " - hwmon: (asus_atk0110) Check package count before accessing element", " - riscv: probes: save original sp in rethook trampoline", " - s390/monwriter: Reject buffer reuse with different data length", " - mac802154: remove interfaces with RCU list deletion", " - llc: fix SAP refcount leak in llc_ui_autobind()", " - ipvs: use parsed transport offset in SCTP state lookup", " - ipvs: reset full ip_vs_seq structs in ip_vs_conn_new", " - macsec: don't read an unset MAC header in macsec_encrypt()", " - drbd: reject data replies with an out-of-range payload size", " - riscv: Prevent NULL pointer dereference in machine_kexec_prepare()", " - tracing/osnoise: Call synchronize_rcu() when unregistering", " - cgroup/cpuset: rebind mm mempolicy to effective_mems, not mems_allowed", " - pmdomain: imx: Fix i.MX8MP power notifier", " - pmdomain: imx: Fix i.MX8MP VC8000E power up sequence", " - powerpc/pseries: fix memory leak on krealloc failure in papr_init", " - wifi: rt2x00: avoid full teardown before work setup in probe", " - wifi: mac80211: fix memory leak in ieee80211_register_hw()", " - regulator: ltc3676: Fix incorrect IRQSTAT bit offsets", " - Bluetooth: btrtl: validate firmware patch bounds", " - llc: fix SAP refcount leak when creating incoming sockets", " - macsec: fix promiscuity refcount leak in macsec_dev_open()", " - memstick: ms_block: reject a card that reports too many blocks", " - ipvs: fix more places with wrong ipv6 transport offsets", " - ipvs: reload ip header after head reallocation", " - reset: sunxi: fix memory region leak on ioremap failure", " - powerpc/spufs: fix out-of-bounds access in spufs_mem_mmap_access()", " - wifi: mac80211: free ack status frame on TX header build failure", " - wifi: mwifiex: fix permanently busy scans after multiple roam iterations", " - mtd: onenand: samsung: report DMA completion timeouts", " - mtd: mchp23k256: use SPI match data for chip caps", " - mmc: vub300: defer reset until cmd_mutex is unlocked", " - mtd: rawnand: fsl_ifc: return errors for failed page reads", " - mtd: rawnand: lpc32xx_mlc: fail DMA transfers on timeout", " - mtd: rawnand: lpc32xx_slc: fail DMA transfer on completion timeout", " - perf/x86/amd/brs: Fix kernel address leakage", " - ACPI: NFIT: core: Fix acpi_nfit_init() error cleanup", " - ACPI: bus: Introduce devm_acpi_install_notify_handler()", " - ACPI: NFIT: core: Use devm_acpi_install_notify_handler()", " - ACPI: NFIT: core: Fix possible deadlock and missing notifications", " - iio: imu: adis: add IRQF_NO_THREAD to non-FIFO trigger IRQ", " - iio: hid-sensor-rotation: Fix stale or zero output when reading raw", " values", " - iio: invensense: remove redundant initialization of variable period", " - iio: invensense: fix timestamp glitches when switching frequency", " - iio: imu: inv_icm42600: stabilized timestamp in interrupt", " - iio: imu: inv_icm42600: fix timestamping by limiting FIFO reading", " - iio: pressure: mpl115: fix runtime PM leak on read error", " - bitops: make BYTES_TO_BITS() treewide-available", " - iio: common: st_sensors: honour channel endianness in read_axis_data", " - ALSA: aoa: check snd_ctl_new1() return value", " - PCI: altera: Fix resource leaks on probe failure", " - vfio/mlx5: Fix racy bitfields and tighten struct layout", " - PCI: imx6: Fix IMX6SX_GPR12_PCIE_TEST_POWERDOWN handling", " - PCI: controller: Use dev_fwnode() instead of of_fwnode_handle()", " - PCI: mediatek: Convert bool to single quirks entry and bitmap", " - PCI: mediatek: Use generic MACRO for TPVPERL delay", " - PCI: mediatek: Fix IRQ domain leak when port fails to enable", " - PCI: Prevent resource tree corruption when BAR resize fails", " - PCI: Free saved list without holding pci_bus_sem", " - PCI: Fix restoring BARs on BAR resize rollback path", " - PCI: Add kerneldoc for pci_resize_resource()", " - PCI: Move Resizable BAR code to rebar.c", " - PCI: Skip Resizable BAR restore on read error", " - staging: rtl8723bs: core: move constants to right side in comparison", " - staging: rtl8723bs: fix spaces around binary operators", " - staging: rtl8723bs: fix OOB reads in rtw_get_sec_ie(),", " rtw_get_wapi_ie(), and rtw_get_wps_attr()", " - crypto: qat - fix VF2PF work teardown race in adf_disable_sriov()", " - Bluetooth: L2CAP: Fix UAF in channel timeout by holding conn ref", " - mm/shrinker: do not hold RCU lock in shrinker_debugfs_count_show()", " - coresight: etb10: restore atomic_t for shared reading state", " - gpio: sch: use raw_spinlock_t in the irq startup path", " - media: nxp: imx8-isi: Convert to platform remove callback returning void", " - media: nxp: imx8-isi: use devm_pm_runtime_enable() to simplify code", " - media: nxp: imx8-isi: Fix use-after-free on remove", " - netfilter: ebtables: Use vmalloc_array() to improve code", " - netfilter: ebtables: zero chainstack array", " - Bluetooth: L2CAP: cancel pending_rx_work before taking conn->lock", " - Bluetooth: 6lowpan: fix cyclic locking warning on netdev unregister", " - Bluetooth: L2CAP: Fix use-after-free in l2cap_sock_new_connection_cb()", " - smb: client: Improve unlocking of a mutex in cifs_get_swn_reg()", " - smb: client: resolve SWN tcon from live registrations", " - ksmbd: use opener credentials for FSCTL mutations", " - ksmbd: centralize ksmbd_conn final release to plug transport leak", " - ksmbd: track the connection owning a byte-range lock", " - proc: rename proc_setattr to proc_nochmod_setattr", " - proc: protect ptrace_may_access() with exec_update_lock (FD links)", " - writeback: fix race between cgroup_writeback_umount() and", " inode_switch_wbs()", " - perf/x86/intel/uncore: Defer ADL global PMON enable to enable_box()", " - HID: add haptics page defines", " - HID: multitouch: fix out-of-bounds bit access on mt_io_flags", " - mm/slab: do not limit zeroing to orig_size when only red zoning is", " enabled", " - seqlock: Introduce scoped_seqlock_read()", " - seqlock: Change do_task_stat() to use scoped_seqlock_read()", " - proc: protect ptrace_may_access() with exec_update_lock (part 1)", " - treewide: Switch/rename to timer_delete[_sync]()", " - HID: appleir: fix UAF on pending key_up_timer in remove()", " - serial: 8250_mid: Disable DMA for selected platforms", " - hfs/hfsplus: prevent getting negative values of offset/length", " - hfs/hfsplus: fix u32 overflow in check_and_correct_requested_length", " - bpf: Consistently use bpf_rcu_lock_held() everywhere", " - bpf: Allow LPM map access from sleepable BPF programs", " - usb: iowarrior: remove inherent race with minor number", " - usb: atm: ueagle-atm: wait for pre-firmware load in .disconnect()", " - usb: typec: tcpm: Fix VDM type for Enter Mode commands", " - crypto: atmel - Drop explicit initialization of struct", " i2c_device_id::driver_data to 0", " - crypto: atmel-sha204a - drop hwrng quality reduction for ATSHA204A", " - usb: gadget: f_fs: initialize reset_work at allocation time", " - nvmet: return DHCHAP status codes from nvmet_setup_auth()", " - nvmet-auth: validate reply message payload bounds against transfer", " length", " - usb: gadget: f_fs: Tie read_buffer lifetime to ffs_epfile", " - btrfs: check and set EXTENT_DELALLOC_NEW before clearing EXTENT_DELALLOC", " - crypto: qat - fix restarting state leak on allocation failure", " - audit: add audit_log_nf_skb helper function", " - audit: fix potential integer overflow in audit_log_n_hex()", " - regulator: scmi: Simplify with scoped for each OF child loop", " - regulator: scmi: fix of_node refcount leak in scmi_regulator_probe()", " - mm: do file ownership checks with the proper mount idmap", " - exfat: move free cluster out of exfat_init_ext_entry()", " - exfat: remove unnecessary read entry in __exfat_rename()", " - exfat: rename argument name for exfat_move_file and exfat_rename_file", " - exfat: add exfat_get_dentry_set_by_ei() helper", " - exfat: move exfat_chain_set() out of __exfat_resolve_path()", " - exfat: preserve benign secondary entries during rename and move", " - btrfs: fix false IO failure after falling back to buffered write", " - btrfs: fix incorrect buffered IO fallback for append direct writes", " - Bluetooth: hci_core: Enable buffer flow control for SCO/eSCO", " - Bluetooth: separate CIS_LINK and BIS_LINK link types", " - Bluetooth: hci_conn: Fix null ptr deref in hci_abort_conn()", " - KVM: Move kvm_io_bus_get_dev() locking responsibilities to callers", " - seqlock: fix scoped_seqlock_read kernel-doc", " - Bluetooth: hci_core: Remove check of BDADDR_ANY in", " hci_conn_hash_lookup_big_state", " - Bluetooth: hci_sync: Fix attempting to send HCI_Disconnect to BIS handle", " - Bluetooth: 6lowpan: Fix using chan->conn as indication to no remote", " netdev", " - selftests/hid: ensure CKI can compile our new tests on old kernels", " - Bluetooth: btmtk: Fix btmtk.c undefined reference build error harder", " - Bluetooth: btmtk: remove #ifdef around declarations", " - writeback: drop now-unnecessary rcu_barrier() in", " cgroup_writeback_umount()", " - jiffies: Define secs_to_jiffies()", " - jiffies: Cast to unsigned long in secs_to_jiffies() conversion", " - driver core: Fix missing jiffies conversion in", " deferred_probe_extend_timeout()", " - driver core: Guard deferred probe timeout extension with", " delayed_work_pending()", " - tools/testing: add linux/args.h header and fix radix, VMA tests", " - selftests/bpf: Add simple strscpy() implementation", " - bcachefs: avoid truncating fiemap extent length", " - gpio: rockchip: change the GPIO version judgment logic", " - gpio: rockchip: teardown bugs and resource leaks", " - gpio: rockchip: fix generic IRQ chip leak on remove", " - NFSv4/flexfiles: Remove cred local variable dependency", " - iio: resolver: ad2s1210: notify trigger and clear state on fault read", " error", " - iio: temperature: Build mlx90635 with CONFIG_MLX90635", " - vfio: Remove device debugfs before releasing devres", " - PCI: loongson: Override PCIe bridge supported speeds for Loongson-3C6000", " series", " - netpoll: fix a use-after-free on shutdown path", " - mm: shrinker: fix shrinker_info teardown race with expansion", " - NFSv4/flexfiles: Add data structure support for striped layouts", " - mm/khugepaged: write all dirty file folios when collapsing", " - platform/x86: intel-hid: Protect ACPI notify handler against recursion", " - Bluetooth: hci_uart: clear HCI_UART_SENDING when write_work is canceled", " - Bluetooth: ISO: avoid NULL deref of conn in iso_conn_big_sync()", " - fs/ntfs3: rename ni_readpage_cmpr into ni_read_folio_cmpr", " - ksmbd: use __GFP_RETRY_MAYFAIL", " - ksmbd: use opener credentials for ADS I/O", " - cpufreq: Make cpufreq_driver->exit() return void", " - cpufreq: qcom-cpufreq-hw: Fix possible double free", " - nvme: target: rdma: fix ndev refcount leak on queue connect", " - nvmet: fix pre-auth out-of-bounds heap read in Discovery Get Log Page", " - crypto: qat - keep VFs enabled during reset", " - crypto: qat - notify fatal error before AER reset preparation", " - crypto: qat - protect service table iterations with service_lock", " - selftests/mm: pagemap_ioctl: use the correct page size for", " transact_test()", " - iommufd: Set upper bounds on cache invalidation entry_num and entry_len", " - iommu/amd: Don't split flush for amd_iommu_domain_flush_all()", " - dma-buf/udmabuf: skip redundant cpu sync to fix cacheline EEXIST warning", " - i2c: core: fix adapter probe deferral loop", " - xfs: fix null pointer dereference in tracepoint", " - xfs: don't wrap around quota ids in dqiterate", " - xfs: clamp timestamp nanoseconds correctly", " - xfs: don't zap bmbt forks if they are MAXLEVELS tall", " - iommu/vt-d: Clear Present bit before tearing down context entry", " - iommu: Pass old domain to set_dev_pasid op", " - iommu/vt-d: Cleanup intel_context_flush_present()", " - iommu/vt-d: Clear Present bit before tearing down scalable-mode context", " entry", " - vsock/virtio: bind uarg before filling zerocopy skb", " - iommu/amd: Use maximum Event log buffer size when SNP is enabled on", " Family 0x19", " - iommu/amd: Use maximum PPR log buffer size when SNP is enabled on Family", " 0x19", " - net: dropreason: Gather SOCKET_ drop reasons.", " - af_unix: Set drop reason in unix_release_sock().", " - af_unix: Set drop reason in manage_oob().", " - af_unix: Set drop reason in unix_stream_read_skb().", " - af_unix/scm: fix whitespace errors", " - af_unix: Don't hold unix_state_lock() in __unix_dgram_recvmsg().", " - af_unix: Don't check SOCK_DEAD in unix_stream_read_skb().", " - af_unix: Don't use skb_recv_datagram() in unix_stream_read_skb().", " - af_unix: Drop all SCM attributes for SOCKMAP.", " - time/jiffies: Change register_refined_jiffies() to void __init", " - media: uvcvideo: Fix dev_sof filtering in hw timestamp", " - media: uvcvideo: Relax the constrains for interpolating the hw clock", " - media: uvcvideo: Do not add clock samples with small sof delta", " - serial: max310x: replace bare use of 'unsigned' with 'unsigned int'", " (checkpatch)", " - serial: max310x: implement gpio_chip::get_direction()", " - drm/gpuvm: Do not prepare NULL objects", " - selftests/bpf: Use local type for bpf_fou_encap in test_tunnel_kern", " - soc: xilinx: Shutdown and free rx mailbox channel", " - crypto: qat - fix heartbeat error injection", " - memory: tegra: Wire up system sleep PM ops", " - drm/gpuvm: take refcount on DRM device", " - ARM: multi_v7_defconfig: Correct QCOM_RPMH and QCOM_RPMHPD", " - RDMA/hns: Initialize seqfile before creating file", " - selftests/bpf: Reject unsupported -k option in vmtest.sh", " - media: atomisp: gc2235: fix UAF and memory leak", " - staging: media: atomisp: fix loop shadowing in ia_css_stream_destroy()", " - arm64: dts: qcom: sm8650: Add power-domain and iface clk for ice node", " - Revert \"treewide: Fix probing of devices in DT overlays\"", " - RDMA/hns: Fix log flood after cmd_mbox failure", " - net: introduce page_frag_cache_drain()", " - nvmet-tcp: fix page fragment cache leak in error path", " - amba: use generic driver_override infrastructure", " - cdx: use generic driver_override infrastructure", " - Drivers: hv: vmbus: use generic driver_override infrastructure", " - driver core: Use system_percpu_wq instead of system_wq", " - tick/sched: Fix TOCTOU in nohz idle time fetch", " - vhost: fix vhost_get_avail_idx for a non empty ring", " - perf/x86/intel/uncore: Fix discovery unit lookup for multi-die systems", " - x86/cpu/amd: Provide a separate accessor for Node ID", " - perf/x86/amd/uncore: Use Node ID to identify DF and UMC domains", " - xfrm: fix NAT-related field inheritance in SA migration", " - netfilter: nfnetlink_cthelper: use {READ,WRITE}_ONCE for accessing", " helper flags", " - netfilter: synproxy: drop packets if timestamp adjustment fails", " - netfilter: synproxy: adjust duplicate timestamp options", " - netfilter: synproxy: fix unaligned memory access in timestamp adjustment", " - RDMA/siw: Fix endpoint/socket association handling", " - riscv: cpu_ops: Change return value type of cpu_is_stopped() to bool", " - wifi: mt76: mt7925: clean up DMA on probe failure", " - wifi: mt76: mt7925: fix potential tx_retries underflow", " - wifi: mt76: mt7996: fix potential tx_retries underflow", " - btrfs: fix deadlock cloning inline extent when using flushoncommit", " - virtio_console: read size from config space during device init", " - ext4: validate donor file superblock early in EXT4_IOC_MOVE_EXT", " - Bluetooth: eir: Fix stack OOB write when prepending the Flags AD", " - Bluetooth: hci_core: Fix UAF in hci_unregister_dev()", " - net: dsa: qca8k: fix led devicename when using external mdio bus", " - ALSA: seq: Drop superfluous filter argument of get_event_dest_client()", " - ALSA: seq: Fix kernel heap address leak in bounce_error_event()", " - net: ethernet: mtk_wed: fix loading WO firmware for MT7986", " - octeontx2-af: npc: Fix size of entry2cntr_map", " - net: ethernet: mtk_wed: debugfs: correct index in wed_amsdu_show()", " - dpll: add reference-sync netlink attribute", " - dpll: move xa_erase() call in to match dpll_pin_alloc() error path order", " - dpll: add reference sync get/set", " - dpll: Allow associating dpll pin with a firmware node", " - dpll: Add notifier chain for dpll events", " - dpll: Support dynamic pin index allocation", " - dpll: Enhance and consolidate reference counting logic", " - dpll: fix stale iteration in dpll_pin_on_pin_unregister()", " - dpll: send delete notification before unregister in on-pin rollback", " - dpll: emit per-dpll delete notifications in dpll_pin_on_pin_unregister()", " - dpll: guard sync-pair removal on full pin unregister", " - dpll: balance create/delete notifications in __dpll_pin_(un)register", " - landlock: Fix unmarked concurrent access to socket family", " - selftests/bpf: Fix typo in verify_umulti_link_info", " - udf: fix nls leak on udf_fill_super() failure", " - mfd: rsmu: Fix page register setup", " - eventpoll: expand top-of-file overview / locking doc", " - eventpoll: rename attach_epitem() to ep_attach_file()", " - eventpoll: rename ep_remove_safe() back to ep_remove()", " - eventpoll: split ep_insert() into alloc + register stages", " - eventpoll: extract ep_deliver_event() from ep_send_events()", " - eventpoll: wrap EP_UNACTIVE_PTR in typed sentinel helpers", " - eventpoll: rename epi->next and txlist for clarity", " - eventpoll: Fix epoll_wait() report false negative", " - gpiolib: acpi: Only trigger ActiveBoth interrupts on boot", " - coresight: Fix source not disabled on idr_alloc_u32 failure", " - PCI: qcom: Disable ASPM L0s for SA8775P", " - dmaengine: dma-axi-dmac: use DMA pool to manange DMA descriptor", " - PCI: meson: Add missing remove callback", " - xprtrdma: Fix ep kref imbalance on ADDR_CHANGE", " - Revert \"PCI/MSI: Unmap MSI-X region on error\"", " - apparmor: remove or add symlinks to rawdata according to export_binary", " - workqueue: Add new WQ_PERCPU flag", " - i3c: master: add WQ_PERCPU to alloc_workqueue users", " - i3c: master: Make hot-join workqueue freezable to block hot-join during", " suspend", " - xfrm: Fix xfrm state cache insertion race", " - mac802154: Prevent overwrite return code in", " mac802154_perform_association()", " - netfilter: ipset: make sure gc is properly stopped", " - mailbox: imx: Forward the timeout/ error in imx_mu_generic_tx()", " - selftest/mm: register existing mapping with userfaultfd in hugetlb-", " mremap", " - selftests/mm: ensure destination is hugetlb-backed in hugetlb-mremap", " - selftests/mm: hugetlb_reparenting_test: do not unmount", " - selftests/mm: save and restore nr_hugepages value", " - selftests/mm: restore default nr_hugepages value via exit trap in", " charge_reserved_hugetlb.sh", " - net/sched: act_ct: fix nf_connlabels leak on two error paths", " - ipv6: annotate data-races around cnf.forwarding", " - ipv6/addrconf: annotate data-races around devconf fields (II)", " - ipv6: ndisc: fix NULL deref in accept_untracked_na()", " - dpaa2-switch: do not accept VLAN uppers while bridged", " - bpftool: Fix vmlinux BTF leak in cgroup commands", " - ice: dpll: set pointers to NULL after kfree in ice_dpll_deinit_info", " - ice: dpll: fix memory leak in ice_dpll_init_info error paths", " - net: bnxt: use ethtool string helpers", " - eth: bnxt: gather and report HW-GRO stats", " - eth: bnxt: rename ring_err_stats -> ring_drv_stats", " - eth: bnxt: improve the timing of stats", " - md/raid5: use stripe state snapshot in break_stripe_batch_list()", " - md/raid5: avoid R5_Overlap races while breaking stripe batches", " - gpio: davinci: fix IRQ domain leak on devm_kzalloc failure", " - ipv6: Add __in6_dev_get_rtnl_net().", " - octeontx2-af: Validate NIX maximum LFs correctly", " - udp_tunnel: remove rtnl_lock dependency", " - net: udp_tunnel: prevent double queueing in udp_tunnel_nic_device_sync", " - net: hisilicon: hns3: use ethtool string helpers", " - net: hns3: use string choices helper", " - net: hns3: use hns3_get_ae_dev() helper to reduce the unnecessary middle", " layer conversion", " - net: hns3: use hns3_get_ops() helper to reduce the unnecessary middle", " layer conversion", " - net: hns3: clear hns alarm: comparison of integer expressions of", " different signedness", " - net: hns3: unify copper port ksettings configuration path", " - net: hns3: refactor MAC autoneg and speed configuration", " - net: hns3: fix permanent link down deadlock after reset", " - net: hns3: differentiate autoneg default values between copper and fiber", " - rtnetlink: Add per-netns RTNL.", " - [Config] Set CONFIG_DEBUG_NET_SMALL_RTNL=n", " - rtnetlink: Add assertion helpers for per-netns RTNL.", " - rtnetlink: Define rtnl_net_trylock().", " - ipv6: Convert net.ipv6.conf.${DEV}.XXX sysctl to per-netns RTNL.", " - ipv6: fix missing notification for ignore_routes_with_linkdown", " - ACPI: processor_idle: Mark LPI enter functions as __cpuidle", " - afs: Remove erroneous seq |= 1 in volume lookup loop", " - afs: Make /afs/. as well as /afs/ mountpoints", " - afs: Add rootcell checks", " - afs: Make /afs/@cell and /afs/.@cell symlinks", " - afs: Fix afs_atcell_get_link() to handle RCU pathwalk", " - afs: Remove the \"autocell\" mount option", " - afs: Change dynroot to create contents on demand", " - afs: Fix misplaced inc of net->cells_outstanding", " - afs: Fix missing NULL pointer check in afs_break_some_callbacks()", " - ovl: fix comment about locking order", " - ata: libata-scsi: limit simulated SCSI command copy to response length", " - net/mlx5: LAG, MPESW, Fix missing complete() on devcom error", " - ipv6: fib6: fix NULL deref in fib6_walk_continue() on multi-batch dump", " - afs: Convert comma to semicolon", " - afs: Fix double netfs initialisation in afs_root_iget()", " - drm/xe: Add warn when level can not be zero.", " - drm/xe/pt: Fix NULL pointer dereference in xe_pt_zap_ptes_entry()", " - drm/xe/hw_engine: Fix double-free of managed BO in error path", " - HID: bpf: Fix hid_bpf_get_data() range check", " - drm/v3d: Reject invalid indirect BO handle in indirect CSD setup", " - perf/x86/amd/core: Avoid enabling BRS from the SVM reload path", " - genirq/generic_chip: Introduce irq_domain_{alloc,remove}_generic_chips()", " - gpio: mvebu: free generic chips on unbind", " - netfilter: nft_lookup: fix catchall element handling with inverted", " lookups", " - drm/xe: remove duplicate include", " - LoongArch: KVM: Check irq validity in kvm_vcpu_ioctl_interrupt()", " - LoongArch: KVM: Check the return values for put_user()", " - LoongArch: KVM: Fix FPU register width with user access API", " - LoongArch: KVM: Return full old CSR value from kvm_emu_xchg_csr()", " - KVM: arm64: nv: Fix SPSR_EL2 restore in kvm_hyp_handle_mops()", " - fbdev: efifb: fix memory leak in efifb_probe()", " - netfilter: nft_set_pipapo: don't leak bad clone into future transaction", " - selinux: avoid sk_socket dereference in selinux_sctp_bind_connect()", " - batman-adv: mcast: avoid OOB read of num_dests header", " - mm/memory_hotplug: fix incorrect altmap passing in error path", " - fs/proc/task_mmu: fix hugetlb self-deadlock in pagemap_scan_pte_hole()", " - fs/proc/task_mmu: use huge_page_size() in pagemap_scan_hugetlb_entry()", " - mtd: spi-nor: spansion: use die erase for multi-die devices only", " - mtd: rawnand: Pause continuous reads at block boundaries", " - taskstats: retain dead thread stats in TGID queries", " - platform/x86: dell-laptop: fix missing cleanups in init error path", " - platform/x86/amd/pmc: Don't log during intermediate wakeups", " - NFS: Charge unstable writes by request size, not folio size", " - netdev-genl: report NAPI thread PID in the caller's pid namespace", " - dm-verity: avoid double increment of &use_bh_wq_enabled", " - dm-verity: make error counter atomic", " - accel/ivpu: Reject firmware log with size smaller than header", " - firmware_loader: introduce __free() cleanup hanler", " - Input: ims-pcu - fix firmware leak in async update", " - tracing/user_events: Fix use-after-free in user_event_mm_dup()", " - gpio: tegra: do not call pinctrl for GPIO direction", " - platform/x86/amd/pmc: Avoid logging \"(null)\" for DMI values", " - s390: Revert support for DCACHE_WORD_ACCESS", " - [Config] Set CONFIG_DCACHE_WORD_ACCESS=- for s390x", " - selftests: net: make busywait timeout clock portable", " - ata: libata: Use QUIRK instead of HORKAGE", " - ata: libata-core: Skip HPA resize for locked drives", " - mmc: sdhci-of-dwcmshc: check bus clock enable result in the probe()", " method", " - ALSA: hda/cs35l41: Fix firmware load work teardown", " - io_uring/rw: ensure reissue path is correctly handled for IOPOLL", " - io_uring/rw: preserve partial result for iopoll", " - Bluetooth: L2CAP: Fix not tracking outstanding TX ident", " - mm: swap_cgroup: fix NULL deref in lookup_swap_cgroup_id on swapless", " host", " - ksmbd_vfs_rename(): vfs_path_parent_lookup() accepts ERR_PTR() as name", " - vfs: make LAST_XXX private to fs/namei.c", " - ksmbd: fix path resolution in ksmbd_vfs_kern_path_create", " - HID: pidff: Fix missing blank lines after declarations", " - HID: pidff: Add missing spaces", " - HID: pidff: Rework pidff_upload_effect", " - HID: pidff: Use correct effect type in effect update", " - bpf, arm64, powerpc: Add bpf_jit_bypass_spec_v1/v4()", " - USB: iowarrior: fix use-after-free on disconnect race", " - crypto: atmel-sha204a - fail on hwrng registration error in probe path", " - btrfs: concentrate the error handling of submit_one_sector()", " - btrfs: remove folio parameter from ordered io related functions", " - btrfs: remove the COW fixup mechanism", " - slab: Introduce kmalloc_obj() and family", " - slab: Introduce kmalloc_flex() and family", " - add default_gfp() helper macro and use it in the new *alloc_obj()", " helpers", " - default_gfp(): avoid using the \"newfangled\" __VA_OPT__ trick", " - slab: recognize @GFP parameter as optional in kernel-doc", " - fscrypt: Fix key setup in edge case with multiple data unit sizes", " - fscrypt: Replace mk_users keyring with simple list", " - KVM: arm64: Ensure level is always initialized when relaxing perms", " - KVM: arm64: Fix propagation of TLBI level in", " kvm_pgtable_stage2_relax_perms()", " - bpf: Reject BPF_MAP_TYPE_INODE_STORAGE creation if BPF LSM is", " uninitialized", " - rtnetlink: Make per-netns RTNL dereference helpers to macro.", " - afs: Fix afs_atcell_get_link() to check if ws_cell is unset first", " - afs: Fix afs_dynroot_readdir() to not use the RCU read lock", " - udp_tunnel: fix deadlock in udp_tunnel_nic_set_port_priv()", " - i40e: drop udp_tunnel_get_rx_info() call from i40e_open()", " - ice: drop udp_tunnel_get_rx_info() call from ndo_open()", " - Bluetooth: L2CAP: Fix regressions caused by reusing ident", " - Bluetooth: L2CAP: fix tx ident leak for commands without a response", " - dpll: fix NULL pointer dereference in dpll_msg_add_pin_ref_sync()", " - perf: Reject exited events as group leaders", " - serial: 8250_mid: Fix NULL function pointer dereference on DNV/ICX-D/SNR", " platforms", " - usb: atm: ueagle-atm: reject descriptors that confuse probe and", " disconnect", " - proc: Fix broken error paths for namespace links", " - Upstream stable to v6.6.145, v6.12.96, v6.12.97", "", " * Noble update: upstream stable patchset 2026-09-10 (LP: #2166995) //", " CVE-2026-53365", " - vsock/virtio: fix zerocopy completion for multi-skb sends", "", " * Noble update: upstream stable patchset 2026-09-10 (LP: #2166995) //", " CVE-2025-37964 -- to the 6.1, 6.6 and 6.12 trees ended up with two", " - x86/mm: Fix check/use ordering in switch_mm_irqs_off()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192)", " - debugobjects: Allow to refill the pool before SYSTEM_SCHEDULING", " - debugobjects: Use LD_WAIT_CONFIG instead of LD_WAIT_SLEEP", " - debugobjects: Dont call fill_pool() in early boot hardirq context", " - ARM: group is_permission_fault() with is_translation_fault()", " - ARM: allow __do_kernel_fault() to report execution of memory faults", " - ARM: fix branch predictor hardening", " - RDMA/bnxt_re: zero shared page before exposing to userspace", " - selftests/bpf: Add test to ensure kprobe_multi is not sleepable", " - bpf: Remove mark_precise_scalar_ids()", " - selftests/bpf: Tests for per-insn sync_linked_regs() precision tracking", " - selftests/bpf: Update comments find_equal_scalars->sync_linked_regs", " - hv: utils: handle and propagate errors in kvp_register", " - Drivers: hv: vmbus: Improve the logic of reserving fb_mmio on Gen2 VMs", " - phonet: Pass ifindex to fill_addr().", " - phonet: Pass net and ifindex to phonet_address_notify().", " - scripts/sorttable: Remove unused macro defines", " - scripts/sorttable: Remove unused write functions", " - scripts/sorttable: Remove unneeded Elf_Rel", " - scripts/sorttable: Have the ORC code use the _r() functions to read", " - scripts/sorttable: Make compare_extable() into two functions", " - scripts/sorttable: Convert Elf_Ehdr to union", " - scripts/sorttable: Replace Elf_Shdr Macro with a union", " - scripts/sorttable: Convert Elf_Sym MACRO over to a union", " - scripts/sorttable: Add helper functions for Elf_Ehdr", " - scripts/sorttable: Add helper functions for Elf_Shdr", " - scripts/sorttable: Add helper functions for Elf_Sym", " - scripts/sorttable: Use uint64_t for mcount sorting", " - scripts/sorttable: Move code from sorttable.h into sorttable.c", " - scripts/sorttable: Get start/stop_mcount_loc from ELF file directly", " - scripts/sorttable: Use a structure of function pointers for elf helpers", " - arm64: scripts/sorttable: Implement sorting mcount_loc at boot for arm64", " - [Config] Set configs to sort mcount_loc at boot for arm64", " - scripts/sorttable: Have mcount rela sort use direct values", " - scripts/sorttable: Always use an array for the mcount_loc sorting", " - scripts/sorttable: Zero out weak functions in mcount_loc table", " - ftrace: Update the mcount_loc check of skipped entries", " - ftrace: Have ftrace pages output reflect freed pages", " - ftrace: Do not over-allocate ftrace memory", " - ftrace: Test mcount_loc addr before calling ftrace_call_addr()", " - ftrace: Check against is_kernel_text() instead of kaslr_offset()", " - scripts/sorttable: Use normal sort if theres no relocs in the mcount", " section", " - scripts/sorttable: Allow matches to functions before function entry", " - scripts/sorttable: Fix endianness handling in build-time mcount sort", " - file: add fput() cleanup helper", " - eventpoll: use hlist_is_singular_node() in __ep_remove()", " - Revert \"ptp: add testptp mask test\"", " - Bluetooth: btmtk: validate WMT event SKB length before struct access", " - Bluetooth: btmtk: accept too short WMT FUNC_CTRL events", " - batman-adv: tp_meter: keep unacked list in ascending ordered", " - batman-adv: tp_meter: initialize dup_acks explicitly", " - batman-adv: tp_meter: initialize dec_cwnd explicitly", " - batman-adv: tp_meter: avoid window underflow", " - batman-adv: tp_meter: fix fast recovery precondition", " - batman-adv: tp_meter: handle seqno wrap-around for fast recovery", " detection", " - batman-adv: tp_meter: add only finished tp_vars to lists", " - batman-adv: bla: annotate lasttime access with READ/WRITE_ONCE", " - batman-adv: prevent ELP transmission interval underflow", " - batman-adv: tp_meter: initialize last_recv_time during init", " - batman-adv: ensure bcast is writable before modifying TTL", " - batman-adv: fix (m|b)cast csum after decrementing TTL", " - batman-adv: frag: ensure fragment is writable before modifying TTL", " - batman-adv: frag: avoid underflow of TTL", " - batman-adv: tp_meter: annotate last_recv_time access with", " READ/WRITE_ONCE", " - batman-adv: tp_meter: prevent parallel modifications of last_recv", " - batman-adv: tp_meter: handle overlapping packets", " - batman-adv: tt: don't merge change entries with different VIDs", " - batman-adv: tt: track roam count per VID", " - batman-adv: dat: prevent false sharing between VLANs", " - batman-adv: tvlv: enforce 2-byte alignment", " - batman-adv: tvlv: avoid race of cifsnotfound handler state", " - inet: add indirect call wrapper for getfrag() calls", " - err.h: use __always_inline on all error pointer helpers", " - wifi: mt76: mt76x2u: Add support for ELECOM WDC-867SU3S", " - wifi: rtlwifi: rtl8821ae: Fix C2H bit location in RX descriptor", " - wifi: rtw88: increase TX report timeout to fix race condition", " - wifi: iwlwifi: mvm: fix race condition in PTP removal", " - f2fs: fix to round down start offset of fallocate for pin file", " - f2fs: keep atomic write retry from zeroing original data", " - MIPS: DEC: Prevent initial console buffer from landing in XKPHYS", " - fbdev: modedb: Fix misaligned fields in the 1920x1080-60 mode", " - nfsd: check get_user() return when reading princhashlen", " - NFS: Prevent resource leak in nfs_alloc_server()", " - serial: qcom_geni: Fix RX DMA stall when SE_DMA_RX_LEN_IN is zero", " - wifi: mt76: mt7921: avoid undesired changes of the preset regulatory", " domain", " - ACPI: scan: Use async schedule function in acpi_scan_clear_dep_fn()", " - xfs: fix error returns in CoW fork repair", " - locking/mutex: Remove wakeups from under mutex::wait_lock", " - net: ipv6: Make udp_tunnel6_xmit_skb() void", " - Revert \"PCI: qcom: Advertise Hotplug Slot Capability with no Command", " Completion support\"", " - KVM: SEV: Ignore MMIO requests of length '0'", " - mtd: spi-nor: macronix: Add post_sfdp fixups for Quad Input Page Program", " - mtd: spi-nor: macronix: add support for mx66{l2, u1}g45g", " - LoongArch: Report dying CPU to RCU in stop_this_cpu()", " - MIPS: smp: report dying CPU to RCU in stop_this_cpu()", " - locking: rtmutex: Fix wake_q logic in task_blocks_on_rt_mutex", " - bonding: annotate data-races arcound churn variables", " - Upstream stable to v6.6.144, v6.12.95", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53389", " - net/tcp-ao: fix use-after-free of key in del_async path", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53393", " - nfsd: reset write verifier on deferred writeback errors", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53400", " - i2c: core: fix adapter registration race", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63806", " - KVM: Replace guest-triggerable BUG_ON() in ioeventfd datamatch with", " get_unaligned()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63940", " - KVM: SEV: Ignore Port I/O requests of length '0'", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53387", " - iio: light: veml6075: add bounds check to veml6075_it_ms index", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53070", " - sctp: disable BH before calling udp_tunnel_xmit_skb()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-43216", " - net: Drop the lock in skb_may_tx_timestamp()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-64244", " - drivers/base/memory: set mem->altmap after successful device", " registration", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53384", " - serial: 8250_dw: unregister 8250 port if clk_notifier_register() fails", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53390", " - ksmbd: fix out-of-bounds read in smb_check_perm_dacl()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53391", " - NFSv4/pNFS: reject zero-length r_addr in nfs4_decode_mp_ds_addr", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53397", " - nfsd: fix posix_acl leak on SETACL decode failure", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53398", " - NFSD: Fix SECINFO_NO_NAME decode error cleanup", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-64245", " - fbdev: modedb: fix a possible UAF in fb_find_mode()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53403", " - fbdev: Fix fb_new_modelist to prevent null-ptr-deref in", " fb_videomode_to_var", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-64246", " - power: reset: linkstation-poweroff: fix use-after-free in the", " linkstation_poweroff_init()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63794", " - KVM: SVM: Fix page overflow in sev_dbg_crypt() for ENCRYPT path", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-64247", " - KVM: x86: hyper-v: Bound the bank index when querying sparse banks", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63795", " - 9p: avoid putting oldfid in p9_client_walk() error path", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63796", " - ocfs2: reject oversized group bitmap descriptors", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63797", " - rpmsg: char: Fix use-after-free on probe error path", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-64249", " - fpga: region: fix use-after-free in child_regions_with_firmware()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63798", " - irqchip/imgpdc: Fix resource leak, add missing chained handler cleanup", " on remove", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63800", " - pNFS: Fix use-after-free in pnfs_update_layout()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63801", " - tipc: fix slab-use-after-free Read in tipc_aead_decrypt_done", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63802", " - blk-cgroup: fix UAF in __blkcg_rstat_flush()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63803", " - hdlc_ppp: sync per-proto timers before freeing hdlc state", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63804", " - gfs2: fix use-after-free in gfs2_qd_dealloc", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63808", " - exfat: fix potential use-after-free in exfat_find_dir_entry()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63809", " - bpf: use kvfree() for replaced sysctl write buffer", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63812", " - f2fs: fix incorrect FI_NO_EXTENT handling in __destroy_extent_node()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63814", " - f2fs: validate ACL entry sizes in f2fs_acl_from_disk()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63817", " - f2fs: validate compress cache inode only when enabled", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63821", " - wifi: rtw88: usb: fix memory leaks on USB write failures", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63822", " - wifi: ath11k: fix warning when unbinding", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63823", " - keys: Pin request_key_auth payload in instantiate paths", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63824", " - KEYS: fix overflow in keyctl_pkey_params_get_2()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63826", " - fbdev: fix use-after-free in store_modes()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-64254", " - NTB: epf: Avoid pci_iounmap() with offset when PEER_SPAD and CONFIG", " share BAR", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63827", " - apparmor: fix use-after-free in rawdata dedup loop", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63828", " - apparmor: mediate the implicit connect of TCP fast open sendmsg", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63830", " - net: skmsg: preserve sg.copy across SG transforms", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63831", " - mac802154: llsec: add skb_cow_data() before in-place crypto", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53361", " - af_unix: Set gc_in_progress to true in unix_gc().", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63833", " - ntfs3: reject direct userspace writes to reserved $LX* xattrs", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53366", " - ipv4: account for fraggap on the paged allocation path", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53362", " - ipv6: account for fraggap on the paged allocation path", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63834", " - batman-adv: tp_meter: restrict number of unacked list entries", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63835", " - batman-adv: v: prevent OGM aggregation on disabled hardif", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63836", " - batman-adv: tp_meter: avoid divide-by-zero for dec_cwnd", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-63807", " - KVM: x86/mmu: Ensure hugepage is in by slot before checking max mapping", " level", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53381", " - virtiofs: fix UAF on submount umount", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53382", " - media: vidtv: fix NULL pointer dereference in vidtv_mux_push_si", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53383", " - ksmbd: reject non-VALID session in compound request branch", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53385", " - vc_screen: fix null-ptr-deref in vcs_notifier() during concurrent", " vcs_write", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53388", " - fuse: re-lock request before replacing page cache folio", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53157", " - net: phonet: free phonet_device after RCU grace period", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53163", " - locking/rtmutex: Skip remove_waiter() when waiter is not enqueued", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2025-23131", " - dlm: prevent NPD when writing a positive value to event_done", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-46252", " - regulator: core: fix locking in regulator_resolve_supply() error path", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-52928", " - af_unix: Reject SIOCATMARK on non-stream sockets", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-43010", " - bpf: Reject sleepable kprobe_multi programs at attach time", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53325", " - agp/amd64: Fix broken error propagation in agp_amd64_probe()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-64188", " - net: qualcomm: rmnet: fix endpoint use-after-free in rmnet_dellink()", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-64191", " - i2c: stub: Reject I2C block transfers with invalid length", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53327", " - debugobjects: Do not fill_pool() if pi_blocked_on", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-52909", " - ip6_vti: set netns_immutable on the fallback device.", "", " * Noble update: upstream stable patchset 2026-09-02 (LP: #2166192) //", " CVE-2026-53167", " - fuse: limit FUSE_NOTIFY_RETRIEVE to uptodate folios", "" ], "package": "linux", "version": "6.8.0-147.147", "urgency": "medium", "distributions": "noble", "launchpad_bugs_fixed": [ 2168142, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2168026, 2071590, 2160493, 2162917, 2165140, 2165732, 2167237, 2167237, 2166995, 2166995, 2166995, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192, 2166192 ], "author": "Stefan Bader ", "date": "Thu, 24 Sep 2026 11:03:24 +0200" } ], "notes": "linux-modules-6.8.0-147-generic version '6.8.0-147.147' (source package linux version '6.8.0-147.147') was added. linux-modules-6.8.0-147-generic version '6.8.0-147.147' has the same source package name, linux, as removed package linux-modules-6.8.0-146-generic. As such we can use the source package version of the removed package, '6.8.0-146.146', as the starting point in our changelog diff. Kernel packages are an example of where the binary package name changes for the same source package. Using the removed package source package version as our starting point means we can still get meaningful changelog diffs even for what appears to be a new package.", "is_version_downgrade": false } ], "snap": [] }, "removed": { "deb": [ { "name": "linux-image-6.8.0-146-generic", "from_version": { "source_package_name": "linux-signed", "source_package_version": "6.8.0-146.146", "version": "6.8.0-146.146" }, "to_version": { "source_package_name": null, "source_package_version": null, "version": null }, "cves": [], "launchpad_bugs_fixed": [], "changes": [], "notes": null, "is_version_downgrade": false }, { "name": "linux-modules-6.8.0-146-generic", "from_version": { "source_package_name": "linux", "source_package_version": "6.8.0-146.146", "version": "6.8.0-146.146" }, "to_version": { "source_package_name": null, "source_package_version": null, "version": null }, "cves": [], "launchpad_bugs_fixed": [], "changes": [], "notes": null, "is_version_downgrade": false } ], "snap": [] }, "notes": "Changelog diff for Ubuntu 24.04 noble image from release image serial 20261008 to 20261017", "from_series": "noble", "to_series": "noble", "from_serial": "20261008", "to_serial": "20261017", "from_manifest_filename": "release_manifest.previous", "to_manifest_filename": "manifest.current" }